Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Monitor the CPU loading using ebpf to reduce system call overhead A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. How it works   Kernel (eBPF) User space (C + libbpf) ----------------------- ------------------------- sched_switch tracepoint poll BPF maps every 1 s -> record on-CPU time per core -> compute active % and idle % -> accumulate in BPF Array map print per-core + average   The sched_switch tracepoint context structure is defined manually in cpu_monitor_bpf.c. Output The monitor displays per-core active/idle percentages, with the idle column matching top's id field for easy comparison:   CPU Core   | Active %   | Idle % (=top id) ------------------------------------------- CPU 0      |     0.34%  |         99.66% CPU 1      |    21.89%  |         78.11% CPU 2      |     0.15%  |         99.85% CPU 3      |     0.03%  |         99.97% ------------------------------------------- TOTAL AVG  |     5.60%  |         94.40%   To compare with top, press 1 in top to show per-core stats, then compare the id column with the Idle % column above. Prerequisites Host (build machine) Package Purpose clang + llvm version 21 Compile BPF C source to BPF ELF bpftool Generate BFP skeleton headers aarch64 Poky Toolchain Corss-compile the user-space binary   Install on Ubuntu/Debian: wget https://apt.llvm.org/llvm.sh chmod +x llvm.sh ./llvm.sh 21 apt update apt install -y llvm-21 clang-21 lld-21 lldb-21 update-alternatives --install /usr/bin/llvm-link llvm-link /usr/bin/llvm-link-21 100 update-alternatives --install /usr/bin/clang clang /usr/bin/clang-21 100 update-alternatives --install /usr/bin/llc llc /usr/bin/llc-21 100 llvm-link --version clang --version # install bpftool apt install linux-tools-$(uname -r) Target board Tested Linux kernel == 6.18.20-2.0.0 Tested image == imx-image-full Most BPF configurations are enabled by default. In addition, you need CONFIG_FTRACE=y to enable tracepoint support (required for the sched_switch hook). Build Build the project on your host machine: TOOLCHAIN_PATH=/opt/fsl-imx-internal-wayland/6.18-whinlatter/environment-setup-armv8a-poky-linux ./build_and_deploy.sh   The script will: Source the Poky toolchain environment Run make clean && make all (compiles BPF object, generates skeleton, cross-compiles user-space binary) Install the binary to ./board_deploy/cpu_monitor Deploy and run   # Copy binary to the board scp board_deploy/cpu_monitor root@<board-ip>:/usr/bin/ # Run on the board (root required for eBPF) ssh root@<board-ip> ./cpu_monitor   Press Ctrl+C to exit.   Benchmarking: eBPF vs top A scheduler stress test script is included to compare monitoring overhead between cpu_monitor and top under high scheduling pressure. Run the stress test On the target board, open three terminals:   # Terminal 1: start scheduler pressure (200 threads, 30 seconds) ./stress_sched.sh -t 200 -d 30 # Terminal 2: measure eBPF monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions timeout -s KILL 10 ./cpu_monitor # Terminal 3: measure top monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions top -b -d 1 -n 10 Compare task-clock, instructions, and context-switches from perf stat output. Try different thread counts to observe scaling behavior:   ./stress_sched.sh -t 50 -d 30     # low pressure ./stress_sched.sh -t 200 -d 30    # medium pressure ./stress_sched.sh -t 500 -d 30    # high pressure Result Test environment: i.MX943 (4x Cortex-A55), Linux 6.18.20, 10-second measurement window. Comparison results in free system load: Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.0 ms 263.9 ms 22x CPU usage 0.1% 2.8% 28x instructions 3.38M 197M 58x context-switches 12 17   sys time (kernel time) 5.0ms 199.5ms 40x user time 0 62.1ms     Comparison results in high scheduling pressure (200 threads): Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.6ms 690ms 54x CPU usage 0.1% 6.1% 61x instructions 4.8M 538M 112x context-switches 122 9019 75x sys time (kernel time) 4ms 461ms 115x user time 0 206ms     Project structure ebpf_cpu_usage/ ├── cpu_monitor_bpf.c      # Kernel-side eBPF program (C, compiled to BPF) ├── cpu_monitor.c          # User-space program (C, cross-compiled to aarch64) ├── Makefile               # Build rules ├── build_and_deploy.sh    # One-shot build + package script ├── stress_sched.sh        # Scheduler stress test for benchmarking └── README.md   A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. i.MX Processors
記事全体を表示
lowlight opensource ai-isp test on imx95       There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability FPGA Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Very High Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium High EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) Low FLOL cidautai/FLOL Lightweight CNN High Low SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low Low KinD zhangyhuaee/KinD Retinex + CNN Medium Medium RetinexNet-lite Derived Light CNN Medium High EnlightenGAN-lite Derived Small CNN Very High Low Fast LLIE CNN Various Small CNN High Medium We selected some open-source models and used UVC to perform performance tests on the exip-os08a20 module with no HDR mode. We found that SCI(GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexible, and Robust Low-Light Image Enhancement". · GitHub) computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed.
記事全体を表示
Boot uses C40 to erase and rewrite flash. Hello, I'm having trouble writing to flash memory using the C40 chip in the bootloader. I'm writing a 300KB binary program, and it frequently fails at the 9th data packet (the second block), with only a 1/10 chance of succeeding completely. Could you please check if there's a problem with my C40 chip? The main program I'm writing... Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Is there a problem with my use of Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) for resetting? How can I prevent consecutive resets after 8 attempts, and what function should I use for jumps? func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> required to avoid hard fault After resetting and jumping , will there be any residual data from the previous program? Is it necessary to clean up the RAM? If so , how? Thank you . 回复: boot使用C40擦写flash Hi@ LJH1 Please provide me with a simple demo that can reproduce the problem so I can reproduce your issue. I don't need your complete product project or scattered driver files. 回复: boot使用C40擦写flash RTD Company uses version 4.0.0 as standard.
記事全体を表示
How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? I am using the eIQ Toolkit to train an image classification model with a dataset of approximately 6,000 images. My target is to generate a TensorFlow Lite (TFLite) model that is smaller than 800 KB so that it can run on the MCXN947. My current training configuration is: Model: MobileNetV2 Alpha: 0.35 Pruning: Enabled Output format: TFLite The issue is that the training process takes nearly 24 hours to complete. I would like to know if there are any recommended settings or optimizations that can reduce the training time to around 1–2 hours while still keeping the final model size below 800 KB. Has anyone faced a similar situation? Are there any best practices in the eIQ Toolkit for reducing training time without significantly affecting model accuracy or increasing the model size? Any suggestions would be greatly appreciated. Thank you! FRDM-Training MCXN Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? Hi @sivamankomb  A 24-hour run for ~6,000 images is not expected for a small MobileNetV2-alpha-0.35 transfer-learning job unless training is running on CPU, using a large input size, too many epochs, heavy dynamic augmentation, or doing pruning/QAT throughout the full training run. I think you can refer to the following. Verify CUDA + cuDNN are installed and being used. Use the smallest input resolution that still gives acceptable accuracy; if you are at 224×224, try 128×128 first. Start with a low epoch limit plus early stopping, not a fixed long training run. Disable pruning for the initial training run; Use INT8 TFLite quantization for deployment; Avoid QAT in the first speed-optimized run; Start with “No Augments,”  You can refer to eIQ Toolkit User Guide for specific content BR Harry
記事全体を表示
Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello NXP Team, I am bringing up a custom board based on the i.MX9596 processor with LPDDR5 memory using the i.MX OEI bootloader. I generated the DDR configuration for my custom board using MCUXpresso Config Tools version 26.3. The generated files are: lpddr5_timing.c lpddr5_config.ds peripherals.c peripherals.h pin_mux.c pin_mux.h In the OEI source under boards/mx95lp5/ddr, I found these files: MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c I would like to confirm the correct integration procedure for a custom LPDDR5 board. Should the generated lpddr5_timing.c be used in place of MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c, with OEI_DDR_CONFIG updated to reference the new timing file? Is XIMX95LPD5EVK19_6400mbps_train_timing_a1.c a silicon-specific training file provided by NXP that should remain unchanged for a custom board? OEI uses the following DDR PHY firmware binaries: lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin Can these same firmware binaries be reused on a custom LPDDR5 board as long as the firmware version matches the generated DDR timing configuration? Is the ECC-enabled timing file required only when LPDDR5 ECC is enabled? If ECC is not used on the custom board, is the normal timing file sufficient? Please let me know if any additional files need to be regenerated or modified when migrating from the EVK DDR configuration to a custom LPDDR5 board. Thank you. Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello, 1. Yes, you need to replace the MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c with your custom configuration. 2. That is a different configuration for that specific silicon revision, it can be used as a reference if is your case. If you are not using this configuration, you can leave it untouched. 3. Yes, those binaries can be reused for similar configurations and normal timing file sufficient if you are not using ECC. Best regards.
記事全体を表示
How to Integrate a C++ TFLite Model into a C-Based MCUXpresso Project? Hello NXP Team, I am integrating a TensorFlow Lite Micro model into my MCUXpresso project for the MCXN947. My application is written in C, while the TensorFlow Lite Micro inference code and generated model are in C++. I am encountering compilation and linking issues when combining the C and C++ source files. I have already tried using "extern C", but the issue remains. Could you please advise on the following? Is it recommended to mix C and C++ source files in an MCUXpresso project? What is the recommended approach for integrating a C++ TensorFlow Lite Micro model into a C-based application? Are there any required compiler/linker settings or reference examples for this integration? Any guidance would be greatly appreciated. Thank you. Development Board MCXN
記事全体を表示
WhisperはNPU上で動作しています こんにちは、 私は95 i.MX でCPUに縛られたささやきを動かしています NPUを使ってプロセッシング速度を上げる方法はありますか?opsetは主にCNN向けのようですが、いずれにせよ聞いてみる価値はあるでしょう。 具体的な例を見たことがないので、可能かどうかは分かりません(NPUはCNN専用のようですが?)。 既にこれをやった人はいますか?何か例はありますか?
記事全体を表示
ブート時にはC40を使用してフラッシュメモリを消去し、書き換えます。 こんにちは。ブートローダーでC40チップを使用してフラッシュメモリへの書き込みに問題が発生しています。300KBのバイナリプログラムを作成しているのですが、9番目のデータパケット(2番目のブロック)で頻繁に失敗し、完全に成功する確率は10分の1程度です。C40チップに問題があるかどうか確認していただけないでしょうか?作成中のメインプログラムは… Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) を使用したリセットに問題がありますか? 8 回試行した後に連続リセットを防ぐにはどうすればよいでしょうか?また、ジャンプにはどの関数を使用すればよいでしょうか? func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> ハードフォールトを回避するために必要 リセットとジャンプの後、以前のプログラムの残留データは残りますか? RAMをクリーンアップする必要はありますか? もし必要なら、どのようにすればよいですか? よろしくお願いいたします。 回复: boot使用C40擦写flash こんにちは@ LJH1 問題を再現できる簡単なデモを提供してください。そうすれば、私もあなたの問題を再現できます。製品プロジェクト全体や、散在するドライバファイルは必要ありません。 回复: boot使用C40擦写flash RTD社は標準バージョンとして4.0.0を使用しています。
記事全体を表示
6,000枚の画像データセットでeIQツールキットのトレーニング時間を短縮するにはどうすればいいですか? 私はeIQ Toolkitを使って、約6,000枚の画像からなるデータセットで画像分類モデルを訓練しています。目標は 、800KB 未満のTensorFlow Lite(TFLite)モデルを生成し、 MCXN947上で動作させることです。 現在のトレーニング構成は以下の通りです: モデル:MobileNetV2 アルファ: 0.35 剪定:有効 出力形式: TFLite 問題は、トレーニングの完了にほぼ 24時間 かかることです。最終モデルサイズを800KB未満に抑えつつ、トレーニング時間を1〜2時間程度に短縮できるおすすめの設定や最適化があれば知りたいです。 同じような状況に直面した方はいらっしゃいますか?eIQツールキットには、モデルの精度を大きく損なわずにトレーニング時間を短縮したり、モデルサイズを大きく変えたりするベストプラクティスはありますか? 何かご提案があれば大変ありがたいです。ありがとう! FRDMトレーニング MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? こんにちは、 @sivamankomb さん。 小規模なMobileNetV2-alpha-0.35の移行学習ジョブで、6,000枚以上の画像を24時間かけて実行することは、CPU上でトレーニングが行われている場合、入力サイズが大きい場合、エポックが多すぎる場合、強い動的拡張がある場合、またはトレーニング中ずっとプルノングやQATを行っている場合を除きます。 以下の点を参照できると思います。 CUDAとcuDNNがインストールされ、使用されていることを確認してください。 許容できる精度を維持できる最小の入力解像度を使用してください。224×224を使用している場合は、まず128×128を試してみてください。 固定の長期トレーニングランではなく、低いエポックリミットと早期停止から始めましょう。 初期のトレーニングランでは剪定を無効にし、 展開にはINT8 TFLite量子化を使用します。 最初の速度最適化実行ではQATを避ける。 「強化なし」から始めましょう。 具体的な内容についてはeIQ Toolkitユーザーガイドを参照してください BR ハリー
記事全体を表示
i.MX95 OEIおよびDDR PHYファームウェアへのカスタムLPDDR5タイミングの統合に関する説明 NXPチームの皆様、こんにちは。 i.MX9596プロセッサをベースにしたカスタムボードを、i.MX OEIブートローダーを使ってLPDDR5メモリを導入します。 MCUXpresso Config Toolsバージョン26.3を使用して、自作ボード用のDDR構成を生成しました。生成されたファイルは以下のとおりです。 lpddr5_timing.c lpddr5_config.ds ペリフェラル.c ペリフェラル.h pin_mux.c pin_mux.h OEIソースのboards/mx95lp5/ddrディレクトリ内に、以下のファイルが見つかりました。 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c カスタムLPDDR5ボードの正しい統合手順を確認したいのですが。 生成されたlpddr5_timing.cMIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c の代わりにこれを使用し、OEI_DDR_CONFIG を更新して新しいタイミングファイルを参照するようにしますか? XIMX95LPD5EVK19_6400mbps_train_timing_a1.cはNXPが提供するシリコン専用のトレーニングファイルで、カスタムボードでは変更されないべきでしょうか? OEIは以下のDDR PHYファームウェアバイナリを使用します。 lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin これらの同じファームウェアバイナリは、生成されたDDRのタイミング設定とファームウェアバージョンが一致していれば、カスタムLPDDR5ボード上で再利用できますか? ECC対応タイミングファイルは、LPDDR5 ECCが有効になっている場合にのみ必要ですか?カスタムボードでECCを使用しない場合、通常のタイミングファイルで十分でしょうか? EVK DDR構成からカスタムLPDDR5ボードに移行する際に、再生成または変更が必要な追加ファイルがあればお知らせください。 よろしくお願いします。 Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage こんにちは、 1. はい、MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c をカスタム構成に置き換える必要があります。 2. それはそのシリコンリビジョンごとに異なる構成なので、あなたのCASEであれば参考にCAN。この構成を使っていない場合は、そのままにしておいても構いません。 3. はい、これらのバイナリは類似の構成に再利用でき、通常のタイミングファイルで十分で、ECCを使わない場合は十分です。 よろしくお願いいたします。
記事全体を表示
マイルストーン搭載のimx8mp h264/h265エンコーダーを緊急募集 mimx8mp h264ビデオエンコーダーはマイルストーンでは実行されません ffprobe -v error -show_streams -i でビデオをテストしたとき 出力の1つにhas_b_frames=2 、SPS/PPSがあり、これがマイルストーンがビデオを表示しない原因になっていると推測されます。 これはHantroエンコーダーによって生成されたものですが、 has_b_frames=0に設定する方法が見つかりませんでした。 他のH264エンコーダーでは問題なく動作します エンコードストリームを に has_b_frames=0 にする方法について教えてください Re: Urgent imx8mp h264/h265 encoder with milestone こんにちは、 @itamarlevit さん。 i.MX8MPでの正確なエンコードコマンド/パイプラインを教えてください。 よろしくお願いします、 志明
記事全体を表示
如何缩短 eIQ Toolkit 对包含 6000 张图像的数据集的训练时间? 我正在使用 eIQ Toolkit 训练一个图像分类模型,数据集大约有 6,000 张图像。我的目标是生成一个小于800 KB的 TensorFlow Lite (TFLite) 模型,以便它可以在MCXN947上运行。 我目前的训练配置是: 型号:MobileNetV2 Alpha:0.35 修剪:已启用 输出格式:TFLite 问题在于,整个培训过程需要近24小时才能完成。我想知道是否有任何推荐的设置或优化方法,可以在将最终模型大小保持在800 KB以下的同时,将训练时间缩短到1-2 小时左右。 有人遇到过类似的情况吗?eIQ Toolkit 中是否有任何最佳实践可以在不显著影响模型准确率或增加模型大小的情况下减少训练时间? 任何建议都将不胜感激。谢谢你! FRDM 培训 MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? 嗨@sivamankomb 对于小型 MobileNetV2-alpha-0.35 迁移学习作业来说,除非训练是在 CPU 上运行、使用较大的输入规模、过多的 epoch、大量的动态增强,或者在整个训练过程中进行剪枝/QAT,否则预计不会出现 24 小时运行约 6,000 张图像的情况。 我认为你可以参考以下内容。 确认已安装并正在使用 CUDA + cuDNN。 使用能够保证可接受精度的最小输入分辨率;如果您使用的是 224×224,请先尝试 128×128。 首先设定较低的训练轮数限制并提前停止,而不是进行固定的长时间训练。 初始训练运行禁用剪枝; 部署时使用 INT8 TFLite 量化; 在第一次速度优化运行中避免使用 QAT; 首先选择“无增强功能”, 具体内容请参阅 eIQ Toolkit 用户指南。 BR 哈里
記事全体を表示
关于将自定义 LPDDR5 时序集成到 i.MX95 OEI 和 DDR PHY 固件使用中的说明 您好,NXP团队, 我正在开发一款基于 i.MX9596 处理器和 LPDDR5 内存,并使用 i.MX OEI 引导加载程序的定制电路板。 我使用 MCUXpresso 配置工具 26.3 版为我的定制板生成了 DDR 配置。生成的文件如下: lpddr5_timing.c lpddr5_config.ds 外围设备.c peripherals.h pin_mux.c pin_mux.h 在 OEI 源代码目录 板/mx95lp5/ddr 下,我找到了以下文件: MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c 我想确认一下定制LPDDR5板的正确集成流程。 生成的 lpddr5_timing.c是否可以用此文件代替 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c,并更新 OEI_DDR_CONFIG 以引用新的时序文件? XIMX95LPD5EVK19_6400mbps_train_timing_a1.ca 是 NXP 提供的芯片专用训练文件,定制板需要保持不变吗? OEI 使用以下 DDR PHY 固件二进制文件: lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin 只要固件版本与生成的 DDR 时序配置匹配,这些相同的固件二进制文件是否可以在定制的 LPDDR5 板上重复使用? 是否只有在启用 LPDDR5 ECC 时才需要启用 ECC 的时序文件?如果定制板上未使用 ECC,则普通时序文件是否足够? 从 EVK DDR 配置迁移到定制 LPDDR5 板时,是否需要重新生成或修改任何其他文件?请告知。 谢谢! Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage 你好, 1. 是的,您需要将 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c 替换为您的自定义配置。 2. 这是该特定硅片版本的一种不同配置,如果这是你的情况,可以将其用作参考。如果您不使用此配置,则可以保持不变。 3. 是的,这些二进制文件可以重复用于类似的配置,如果您不使用 ECC,则普通的计时文件就足够了。 顺祝商祺!
記事全体を表示
reliability data request dear NXP As part of our component evaluation process, we would appreciate receiving the reliability report for the MMX9352XVVXMAC this information is crucial for our design considerations. thank you for your support Re: reliability data request Hi Mike, Thank you for your inquiry. Since you are contacting us using a Gmail address rather than a company email address, could you please provide the following information? Your company name Project details End customer name If you prefer not to share these details here, please feel free to reply directly to the email I sent you. I will need this information when requesting the reliability report from our internal quality team. Thank you in advance for your cooperation. I look forward to your reply. Thank you and have a nice day. Re: reliability data request Dear bar mike,   Thanks for reaching out.   Based on the confirmation: the correct part# should MiMX9352XVVXMAC, not MMX9352XVVXMAC you mentioned.   For the reliability report of MiMX9352XVVXMAC, it is not public, I need to check with our internal quality engineer, will provide it to you once I got it.   Thanks in advance for your patience. 
記事全体を表示
可靠性数据请求 尊敬的恩智浦半导体 作为我们元器件评估过程的一部分,我们希望收到 MMX9352XVVXMAC 的可靠性报告,该信息对我们的设计考虑至关重要。 感谢您的支持 Re: reliability data request 您好,迈克, 感谢您的咨询。 由于您使用的是Gmail地址而不是公司电子邮件地址与我们联系,请您提供以下信息? 您的公司名称 项目详情 最终客户姓名 如果您不希望在此处分享这些细节,请直接回复我发送给您的电子邮件。 我在向内部质量团队索取可靠性报告时需要这些信息。 感谢您的合作。 期待您的回复。 谢谢,祝您愉快。 Re: reliability data request 亲爱的酒吧迈克,   感谢您的联系。   根据确认信息:正确的零件号应为 MiMX9352XVVXMAC, 不是 MMX9352XVVXMAC 你提到了。   对于 可靠性报告 关于 MiMX9352XVVXMAC,它不是公开的,我需要向我们内部的质量工程师确认,一旦我得到它,就会提供给您。   感谢您的耐心等待。
記事全体を表示
信頼性データ要求 NXP様 部品評価プロセスの一環として、この情報が設計上の考慮事項に不可欠なMMX9352XVVXMAC信頼性報告書をいただけるとありがたいです。 ご支援ありがとうございます Re: reliability data request こんにちは、Mikeさん お問い合わせいただきありがとうございます。 会社のメールアドレスではなく Gmail アドレスでご連絡いただいているので、以下の情報を教えていただけますか? あなたの会社名 プロジェクトの詳細 最終顧客の名前 これらの詳細をここで共有したくない場合は、私が送信したメールに直接返信してください。 この情報は、社内の品質チームに信頼性レポートを依頼する際に必要になります。 ご協力ありがとうございます。 ご返信をお待ちしております。 ありがとうございました。良い一日をお過ごしください。 Re: reliability data request バーマイク様、   ご連絡ありがとうございます。   確認に基づくと、正しい部品番号はMiMX9352XVVXMACです。 ない MMX9352XVVXMAC あなたが言及しました。   MiMX9352XVVXMACの信頼性レポート  は公開されていません。社内の品質エンジニアに確認する必要があります。届い次第お渡しします。   ご理解とご協力に感謝いたします。
記事全体を表示
在 NPU 上运行的 Whisper 你好, 我一直在 i.MX 95 上运行 Whisper,它受限于 CPU 性能。 是否有办法利用NPU来加快处理速度?看起来这个算式集主要是给 CNN 用的,不过还是值得一问。 我没见过任何例子,而且我不确定这是否可行(NPU 似乎只适用于 CNN?) 有人已经做过这件事了吗?有例子吗?
記事全体を表示
boot使用C40擦写flash 你好,我这边使用boot里面使用C40写flash大概率失败,我写300K左右的bin程序,经常在第9包数据,也就是第二个块就失败,1/10可能性完整通过,请帮我看一下是不是C40是不是使用有问题,写的主要程序 Flash_UnlockSectorIfProtected(cur_sector); DisableAllInterrupts(); DisEnableIrq1(); if (Flash_Write(flash_write_addr + offset, &payload[2], FIXED_PACKET_DATA_LEN) != 0) { EnableIrq1(); EnableAllInterrupts(); } EnableIrq1(); EnableAllInterrupts(); 我使用Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE);复位有没有问题,怎么避免8次后连续复位,跳转函数 func = *(uint32_t volatile *)(ADDR_APP + 0xC); func = *(uint32_t volatile *)(((uint32_t)func) + 0x4); func = ((((uint32_t)func) & 0xFFFFFFFFU)); // Reset_Handler+1 --> required to avoid hard fault (* (void (*) (void)) func)();复位和跳转后会不会有之前程序的数据残留,需要清理ram吗,如果需要怎么清理。麻烦了 回复: boot使用C40擦写flash Hi@LJH1 做一个最简单可以复现问题的demo给我,方便我复现你们的问题,我不要你们的完整产品工程或者是零散的驱动文件。 回复: boot使用C40擦写flash RTD公司统一使用的4.0.0
記事全体を表示
Urgent imx8mp h264/h265 encoder with milestone using imx8mp h264 video encoder is not run on milestone  when testing the video with ffprobe -v error -show_streams -i one of the output is has_b_frames=2 ,  SPS/PPS  we suspect that this cause milestone not to show the video  it produce by hantro encoder but we didn't find way to set it to has_b_frames=0 it in other h264 encoder that work ok  Need help how we can make the encode stream to has has_b_frames=0  Re: Urgent imx8mp h264/h265 encoder with milestone Hi @itamarlevit  Please provide the exact encoding commands/pipeline on i.MX8MP Best Regards, Zhiming
記事全体を表示
急需带里程碑的 imx8mp h264/h265 编码器 使用 imx8mp h264 视频编码器在里程碑版本中未运行。 使用 ffprobe -v error -show_streams -i 测试视频时 其中一项输出是has_b_frames=2 ,SPS/PPS,我们怀疑这是导致里程碑视频无法显示的原因。 它由 Hantro 编码器生成,但我们找不到将其设置为has_b_frames=0 的方法。 它在其他 H264 编码器中运行正常。 需要帮助,如何使编码流具有 has_b_frames=0 属性。 Re: Urgent imx8mp h264/h265 encoder with milestone 嗨@itamarlevit 请提供 i.MX8MP 的确切编码命令/流程。 此致, 志明
記事全体を表示