Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
カメラセンサーOS02G10 MIPI CSI for IMX8MM こんにちは、みんな。 OS02g10のドライバーは以下から入手しました: https://github.com/Shaggy013/kernel-5.10 ドライバーをパッチとして追加しました。 私のデバイスツリーは次のようになっています。 csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; カメラドライバーとmxc_mipi-csi.c用にプローブ機能を修正しました。mx6s-csi.c 以前はフォーマット一致エラーが2回発生しましたが、mx6s-csiに追加しました { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } そしてmxc_mipi-csi.cに追加されました { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } v4l2 APIは正常に動作し、エラーは発生しません。以下は画像を取得するためのコマンドです v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw そして、デバッグメッセージの結果 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) その後は何も起こらず、ただ待って待つだけで何も起こらない。 20MHzオシロスコープではMIPI DATAおよびMIPI CLKラインのトラフィックを観測できません。(帯域幅が低いのは承知していますが、データ回線であれば何らかの変化が見られるはずです。しかし、全く反応がありません。) clkノードが正しいかどうか確信が持てません。クロック名によるmipi_csiクロックと一致する&clkノードがない可能性もあります。どなたか使用経験のある方はいらっしゃいますか? どうすればいいでしょうか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM こんにちは、Linuxのアップストリームドライバーを使えます。 私たちはこれをi.mx8MPベースのDebixプラットフォームでテストしました。 こちらがドライバです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad こちらが当社のDTです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- ルトヴィイ シリコンシグナルズ Re: Camera sensor os02g10 MIPI CSI for IMX8MM うまくいきました。 .bpp2でなければならない しかし主な問題はハードウェアにあった
記事全体を表示
S32K388 GMAC0 Eth_43_GMACドライバーがRX割り込みを受け取らない こんにちは、 私は以下の設定を使用しています。 S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 提供されたEth_InternalLoopback_S32K388例プロジェクトをベースにし、PCからメディアコンバーター経由でフレームを受け取れるように改良しました。例 S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600で言及されていた RTD 修正を追加しました。ブレークポイントを達成できました Eth_43_GMAC_Receive(EthConf_EthCtrlConfig_EthCtrlConfig_0、0U、&Status); そして、イーサネットフレームを点検できました EthIf_RxIndication(Eth_43_GMAC_apxInternalCfg[PartitionId]->Eth_43_GMAC_apCtrlConfig[CtrlIdx]->EthCtrlEthIfIdx, FrameType, IsBroadcast, MacSrcAddr, Payload, PayloadLength, IngressTimeTuplePtr, RxHandleId); しかし、while 1 ループを追加し、Rx 割り込みを有効にして GMAC0_CH0_RX_IRQHandler にリンクしても、どこにも割り込みが発生しませんでした。プロジェクトを以下に添付しました。 James_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.png S32K3 オートモーティブ-RTD  Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、 @James_Zhang_SE さん、 添付のプロジェクトを確認しました。RTD7.0.1でRX IRQを有効にするには、Ingress QueueHandlerFunctionを変更してQueueInterruptを有効にする必要があります。 PavelL_0-1788263577590.pngPavelL_0-1788263577590.pngPavelL_0-1788263577590.pngPavelL_0-1788263577590.png その変更後、GMAC_RxIRQHandler() でブレークポイントに到達しました。Eth_43_GMAC_Receive() にて。 また、RGMII TXCLKが入力として定義されていますが、出力として定義されるべきです。 ただし、WiresharkでTXフレームを見るには、イニットシーケンスを適切に変更する必要があります。 例S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600 。あなたのプロジェクトでは、次のように見え ます: PavelL_1-1788264277735.pngPavelL_1-1788264277735.pngPavelL_1-1788264277735.pngPavelL_1-1788264277735.png よろしくお願いいたします。 パベル Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、パベルさん。 サポートありがとうございます。ご提案の修正を適用した後、GMACドライバーが動作するようになりました。 いくつか追加の質問がありますので、ご教示いただければ幸いです。 GMACドライバーの設定や使用手順を完全に説明した詳細なドキュメントはありますか?まずは自分でドキュメントを確認して、ドライバのことをもっと理解したいと思っています。 EthIf_RxIndication()の中で、呼び出す必要がありますか? Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId); 関数の最後に受信バッファを解放する処理はありますか? GMACの設定オプションは数多く用意されています。各設定パラメータが何をするのか、どのように設定すべきかを説明するドキュメントや参考文献はありますか? ご協力ありがとうございました。皆さんのサポートに本当に感謝しています。 Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、 @James_Zhang_SE さん。 最新情報のご共有ありがとうございます。GMACドライバーが今あなたのために使えるようになったと聞いて安心しました。 追加のご質問について: 1.ドライバーの設定および使用に関する主な参照は、RTDインストールに含まれているEth_43_GMACユーザーマニュアルです。例:C:\NXP\S32DS.3.6.6_RTD701\S32DS\software\PlatformSDK_S32K3\RTD\Eth_43_GMAC_TS_T40D34M70I1R0\doc\RTD_ETH_43_GMAC_UM.pdf 同じディレクトリに保存されている対応するEth_43_GMAC統合マニュアル(RTD_ETH_43_GMAC_IM.pdf)と、利用可能なGMACサンプルプロジェクトも確認することをお勧めします。   2. Eth_43_GMAC_ReleaseRxBuffer() を呼び出す必要があるかどうかは、EthCtrlReleaseResourceAfterReception 設定パラメータによって決まります。 PavelL_0-1789024403441.pngPavelL_0-1789024403441.png 受信後の自動リリースが有効の場合、ドライバーはEthIf_RxIndication()が戻った後にRXリソースを解放するため、明示的にリリースすべきではありません。 自動解放が無効になっている場合、EthIf_RxIndication() が戻った後も、受信バッファは割り当てられたままになります。その場合、アプリケーションは最終的に以下を呼び出さなければなりません。 Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId);   このモードは、アプリケーションが受信データを保持してさらなるプロセッシングを行う必要がある場合に有用です。ただし、バッファはアプリケーションが使用を終えた後に解放されなければなりません。そうしないと、利用可能な受信バッファが最終的に枯渇してしまう。 また、受信したペイロードポインタは、対応するバッファが解放された後は使用しないでください。 3. Eth_43_GMACユーザーマニュアルは個々の構成パラメータの主要な参照資料でもあります。さらに、S32設定ツールでは、対応する設定を選択またはマウスオーバーすると、多くのパラメーターの説明が表示されます。MACフィルタリング、DMA操作、MTLキュー、タイムスタンプ、割り込み状態などのハードウェアレベルの動作については、S32K3リファレンスマニュアルのGMAC/EMAC章を参照してください。 実用的な出発点として、RTDパッケージで提供されているGMACの例を参照することをお勧めします。このページには、lwIPの機能的なサンプルも掲載されています。 https://community.nxp.com/t5/S32K-Knowledge-Base/S32K-Examples/ta-p/1108990 何か問題を感じたら、遠慮なくサポートをお願いしてください。各トピックごとに専用スレッドを設けることが望ましいです。これにより、他のユーザーにとってケースの明確さを保つことができます。 よろしくお願いいたします。 パベル
記事全体を表示
IMX95 datasheet Hello, How can I get imx95 datasheet with register maps, peripherals, etc.? Regards, Artur Re: IMX95 datasheet Thank you and have a nice day Regards, Artur Re: IMX95 datasheet The datasheet alone does not contain the full register maps and peripheral descriptions. For that, you need the https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf. Thanks
記事全体を表示
IMX95 数据手册 你好, 如何获取包含寄存器映射、外设等信息的imx95数据手册? 问候, 阿图尔 Re: IMX95 datasheet 谢谢,祝您愉快! 问候, 阿图尔 Re: IMX95 datasheet 单凭数据手册无法包含完整的寄存器映射和外设描述。 为此,您需要https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf 。 谢谢!
記事全体を表示
LPC1778 IAPプログラミングにおいて、CCLKの値が大きいほどプログラミング速度は遅くなります。 こんにちは。LPC1778のIAPモードを使用してプログラムを書き込んでいたところ、CCLKの値が大きいほど書き込み処理が遅くなることがわかりました。 ほとんどの IAP 命令は CCLK パラメータを受け入れることができます。これはマニュアルでは次のように説明されています: Param3: CPU クロック周波数 (CCLK) (kHz)。 LPC1778のデバッグ中に、ドライバのデフォルトのCCLK値を12000(12MHz)から4000(4MHz)に変更したところ、書き込み速度が実際に向上しました。いくつかの値を試したところ、CCLKパラメータが大きいほど書き込み処理が遅くなることがわかりました。これはなぜでしょうか?CCLKはどの周波数を指しているのでしょうか? 回复: LPC1778 IAP烧录CCLK越大反而烧录越慢 こんにちは@BianHaopeng1 LPC1778/LPC178xのドキュメントでは、CCLKはARMプロセッサのクロック周波数、つまりメインCPUクロック(コアCPUクロック)を指します。IAP消去コマンドでは、CPUクロック周波数(CCLK)をkHz単位で指定する必要があります。 その理由は、「CCLKが低いほど物理的なフラッシュ書き込みが速くなる」ということではなく、IAP ROMルーチンが渡されたCCLKを現在のCPU周波数として扱い、フラッシュ消去/書き込みのタイミング/待機時間を計算しているためである可能性が高い。したがって、実際のCPUがより高い周波数で動作している状態で、IAPに渡されるパラメータを12000から4000に変更した場合、IAPは4MHzに基づいてより短いレイテンシ/タイミングを生成し、書き込みが速くなる。しかし、これはIAPに誤ったクロックが渡されることを意味し、フラッシュ消去/書き込みの信頼性、温度/電圧の許容範囲、および長期安定性が保証されない。 正しい方法は、IAP呼び出し時の実際のCPUクロック速度をkHz単位でCCLKパラメータに入力することです。 BR ハリー Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 LPC1778では、CCLKは水晶発振器の周波数ではなく、実際のCPUコアクロック周波数(kHz単位)を意味します。IAPブートローダーは、特にフラッシュメモリのプログラミングやUART通信において、内部タイミングを計算するためにCCLKパラメータを使用します。提供した値がMCUの実際のCPUクロックと一致しなかったり、クロックがIAPコードの期待値と異なる設定をしていると、タイミング計算が誤り、プログラミングや通信が遅くなることがあります。したがって、PLL/分周器の設定後、CCLKパラメータがCPUクロックと完全に一致するようにしてください(例えば、120MHzは120000kHzと指定する必要があり、12000とは指定しません)。
記事全体を表示
MFRC630とCLRC663は互換性がありますか? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 現在、当社の製品は2台のCLRC663を使用しています。これらは50オームのインピーダンスにマッチングされているため、CLRC663の「高電流」機能を活用しません。未来では制作コストを節約し、1 CLRC663(14443と15693をサポートする必要があるため必要)と1 MFRC630(2つ目のリーダーはmifareのみで済みます)だけを使いたいと考えています。 両方の製品で自社ライブラリをテストすることに成功しましたが、「変更可能な」UIDチップタイプでも動作しているようです 良い。つまり、ソフトウェアの問題ではないということです。私の推測では、MFRC630はCLRC630とは別のファームウェアで、サポートしていないのだと思いますISO15693 フットプリントとピン配置は同じです 唯一気になるのは、マッチングについてです。 ミフェアでマッチングされたCLRC663を、マッチングネットワークを変えずにドロップインMFRC630に置き換えることは可能でしょうか? NFCコントローラーソリューション NFCフロントエンド・ソリューション Re: MFRC630 and CLRC663 Interchangeability? すでに答えは見つかっていると思いますが、これを見つけた方のために、アプリケーションノート(https://www.nxp.com/docs/en/application-note/AN11256.pdf)に「変更は不要」と書かれています。 私もMFRC630を使用するプロジェクトに取り組んでいますが、開発段階ではCLRC663を使用しています。CLRC663用の基板が存在するからです。プロジェクトが終わったら、移行が申請書の通りスムーズに進んだかどうかを確認する投稿を追加します。 Re: MFRC630 and CLRC663 Interchangeability? こんにちは、 @jof さん、 はい、これらのICは「チューニング」に対応しています。シリコンは同じですが、MFRC660 MIFAREテクノロジ(ISO 14443、タイプA)のみをサポートし、CLRC663はタイプA、タイプB、その他すべてのテクノロジをサポートしていますISO15693... BR トマス
記事全体を表示
MFRC630 and CLRC663 Interchangeability? Currently our product uses two pcs of CLRC663. They are matched to 50Ohms impedance, so they will not make use of the "high current" capability of the CLRC663. For the furture, we want to save on production costs and use just one CLRC663 (needed because it must support 14443 and 15693) and one MFRC630 (second reader only needs mifare). I succesfully tested our own library on both products and they seem to work, even with "changeable" uid chip types very well. So it wouldn't be a software thing. My guess is that the MFRC630 is just a different firmware than CLRC630, to not support ISO15693 Footprint and pinout are the same The only thing i wonder is about the matching. Could the CLRC663 which is matched for mifare, replaced by a drop-in MFRC630 without changing the matching network? NFC Controller Solutions NFC Frontend Solutions Re: MFRC630 and CLRC663 Interchangeability? I assume you've already found the answer, but for anyone who might find this, there is an application note ( https://www.nxp.com/docs/en/application-note/AN11256.pdf) which says that no changes need to be made. I am also working on a project which will use the MFRC630, but for development, I'm using CLRC663 because there is a board for it. I shall add a post here after finishing the project, confirming whether the migration went as smoothly as the application note says. Re: MFRC630 and CLRC663 Interchangeability? Hello @jof ,  Yes, the ICs are "tuning" compatible. The silicon is the same but MFRC660 supports only MIFARE technology (ISO 14443, Type A) while the CLRC663 supports all technologies as Type A, Type B, ISO15693...  BR Tomas 
記事全体を表示
适用于 IMX8MM 的 OS02G10 MIPI CSI 摄像头传感器 大家好。 我从以下位置获取了 os02g10 的驱动程序: https://github.com/Shaggy013/kernel-5.10 我以补丁的形式添加了驱动程序。 我的设备树如下所示: csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; 我修改了相机驱动程序和 mxc_mipi-csi.c 的探测函数,mx6s-csi.c 之前我遇到过两次格式匹配错误,但我添加了 mx6s-csi { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } 并添加到 mxc_mipi-csi.c { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } v4l2 API 工作正常,没有错误。以下是我获取图片的命令 v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw 结果以及我的调试信息 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) 之后什么都不会发生,只有等待、等待,什么也不会发生。 我用20MHz示波器观察不到MIPI DATA和MIPI CLK线上的任何信号。(我知道带宽很低,但对于数据线路来说,任何变化都应该能被察觉,然而却一片寂静。) 我不确定clk节点是否正确,也许没有与mipi_csi时钟名称匹配的&clk节点。有人用过吗? 我能做些什么 ? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM 您好,您可以使用我们已向上游提交的 Linux 驱动程序。 我们已在基于 i.mx8mp 的 debix 平台上进行了测试。 这是我们的司机。 https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad 这是我们的DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- 鲁特维 SiliconSignals Re: Camera sensor os02g10 MIPI CSI for IMX8MM 我成功了。 .bpp必须等于 2 但主要问题出在硬件上。
記事全体を表示
Camera sensor os02g10 MIPI CSI for IMX8MM Hi all. I got the driver for os02g10 from: https://github.com/Shaggy013/kernel-5.10 I added driver as a patch. My DeviceTree looks that: csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; I modified probe function for camera driver and for mxc_mipi-csi.c, mx6s-csi.c Before I had 2 times format match error but I added to the mx6s-csi { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } and added to mxc_mipi-csi.c { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } and v4l2 API works, there is no error. Below my command to get picture v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw and the result with my debug messages mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) After that nothing is going to happen, just waiting and waiting and nothing. I can not observe any traffic on MIPI DATA and MIPI CLK lines by 20MHz oscilloscope. (I know the bandwidth is low but for data lines there should be anything seen - any change but there is completely silence)  Im not sure if clk node is correct and maybe there is no match &clk node with mipi_csi clocks by clock names. Has anyone experience with it? What can I do ? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM Hi, you can use our linux upstreamed driver,  we have tested this on i.mx8mp based debix platform.  Here is our driver  https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad Here is our DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- Rutvij  SiliconSignals Re: Camera sensor os02g10 MIPI CSI for IMX8MM I got it to work. .bpp has to be = 2 but main issue was with hardware
記事全体を表示
MFRC630 和 CLRC663 可以互换吗? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 目前我们的产品使用了两颗 CLRC663。它们的阻抗匹配度为 50 欧姆,因此无法利用 CLRC663 的“大电流”能力。展望未来,我们希望节省生产成本,只使用一个 CLRC663(因为它必须支持 14443 和 15693)和一个 MFRC630(第二个读卡器只需要 mifare)。 我已成功在两款产品上测试了我们自己的库,它们似乎都能正常工作,即使是“可变”的uid芯片类型也是如此。 出色地。所以这应该不是软件问题。我猜测MFRC630只是固件版本与CLRC630不同,所以才不支持ISO15693。 封装尺寸和引脚排列相同 我唯一想知道的就是匹配方面的问题。 与 mifare 匹配的 CLRC663 能否在不改变匹配网络的情况下,被即插即用的 MFRC630 取代? NFC 控制器解决方案 NFC 前端解决方案 Re: MFRC630 and CLRC663 Interchangeability? 我假设你已经找到了答案,但为了方便可能看到这条信息的人,这里有一份应用笔记( https://www.nxp.com/docs/en/application-note/AN11256.pdf ),其中指出无需进行任何更改。 我目前也在做一个使用 MFRC630 的项目,但为了开发,我使用的是 CLRC663,因为有相应的开发板。项目完成后,我将在此处发布一篇帖子,确认迁移是否像应用笔记中所说的那样顺利。 Re: MFRC630 and CLRC663 Interchangeability? 你好@jof , 是的,这些集成电路是“调谐”兼容的。虽然芯片相同,但MFRC660仅支持MIFARE技术(ISO 14443,A型),而CLRC663支持所有技术,包括A型、B型、ISO15693等。 BR 托马斯
記事全体を表示
The larger the CCLK for LPC1778 IAP programming, the slower the programming speed. Hello, when I was using the IAP mode of the LPC1778 to burn the program, I found that the larger the CCLK, the slower the burning process became. Most IAP instructions can accept the CCLK parameter, which is described in the manual as: Param3: CPU Clock Frequency (CCLK) in kHz. When debugging the LPC1778, I changed the default CCLK value of the driver from 12000 (12MHz) to 4000 (4MHz), and found that the burning speed actually increased. I tried several values and found that the larger the CCLK parameter, the slower the burning process. What could be the reason for this? What frequency does CCLK refer to? 回复: LPC1778 IAP烧录CCLK越大反而烧录越慢 Hi @BianHaopeng1 In the LPC1778/LPC178x documentation, CCLK refers to the ARM processor clock frequency / Main CPU clock, which is the core CPU clock. The IAP erase command explicitly requires the CPU Clock Frequency (CCLK) to be passed in kHz. The reason is most likely not that "a lower CCLK results in faster physical Flash writes," but rather that the IAP ROM routine treats the CCLK you pass in as the current CPU frequency to calculate the Flash erase/write timings/wait times. Therefore, if the actual CPU is still running at a higher frequency, and you only change the parameter passed to IAP from 12000 to 4000, IAP will generate a shorter latency/timing based on 4 MHz, resulting in faster burning; however, this means that an incorrect clock is being passed to IAP, and the reliability of Flash erase/write, temperature/voltage boundaries, and long-term stability are not guaranteed. The correct approach is to fill in the actual CPU clock speed at the time of the IAP call, in kHz, for the CCLK parameter. BR Harry Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 On the LPC1778, CCLK means the actual CPU core clock frequency (in kHz), not the crystal/XTAL frequency. The IAP bootloader uses the CCLK parameter to calculate its internal timing, particularly for flash programming and UART communication. If the value you provide does not match the MCU’s real CPU clock—or if the clock is configured differently from what the IAP code expects—the timing calculations can become incorrect, causing slower programming or communication. Therefore, make sure the CCLK parameter exactly matches the CPU clock after PLL/divider configuration (e.g., 120 MHz should be specified as 120000 kHz, not 12000).
記事全体を表示
[SPSDK][i.MX95] nxpele 读取公共熔丝失败 您好, 我正在研究如何在 IMX95 19x19 EVK 板上启用安全启动。我已经使用 SPSDK 成功对我的镜像进行了签名。现在,在写入熔丝之前,我想使用 `nxpele` 读取它们,但我遇到了以下错误。 ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-熔丝 --index 136 SPSDK解析错误:SPSDK:响应中的消息大小无效:0x4 请查看调试日志文件:/home/user/.local/state/spsdk/3.11.0/log/debug.log 获取更多信息 ``` 日志中显示以下内容: ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"响应中的消息 SIZE 无效:{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 调试:spsdk:***************************************************(自启动以来已耗时 206 毫秒,spsdk_logger.py:212) DEBUG:spsdk:* SPSDK 调试日志记录已启动 2026-09-03 15:58:44 * (自启动以来耗时 207 毫秒,spsdk_logger.py:213) 调试信息:spsdk:* SPSDK 版本:3.11.0* (自启动以来耗时 207 毫秒,spsdk_logger.py:215) 调试信息:spsdk:* Python 版本:3.14.4* (自启动以来耗时 207 毫秒,spsdk_logger.py:216) 调试:spsdk:* 操作系统版本:Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (自启动以来耗时 208 毫秒,spsdk_logger.py:217) DEBUG:spsdk:* 最后一条命令:['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-熔丝', '--index', '136'] * (自启动以来已过去 208 毫秒,spsdk_logger.py:218) 调试:spsdk:***************************************************(自启动以来已运行 208 毫秒,spsdk_logger.py:219) 跟踪:spsdk.uboot.uboot:Uboot写入 -> 无效(自开始以来已耗时 210 毫秒, __init__ .py:50) 调试:spsdk.uboot.uboot:Uboot读取直到 <- => (自启动以来已过去 210 毫秒,uboot.py:271) 调试:spsdk.uboot.uboot:正在检查如果串口控制台因发送无效命令而打开:“无效\r\n未知命令‘无效’ - 请尝试‘帮助’\r\nu-boot=>”(自启动以来 224 毫秒,uboot.py:209) 调试:spsdk.utils.database:当前数据库指纹哈希值:f0f0598d4e6ae6c755d693693f232e30537cfb3b(自启动以来耗时 226 毫秒,database.py:1967) 调试信息:spsdk.utils.database:已加载从缓存读取数据库:/tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache(自启动以来耗时 226 毫秒,database.py:1976) 调试:spsdk.utils.misc:正在加载从 /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml 读取文本文件(自启动以来耗时 226 毫秒,misc.py:312) 信息:spsdk.ele.ele_comm:ELE通信器在 mimx9596 中使用 92800000 地址处的 196608 B 大小的缓冲区,版本:最新目标。 调试:spsdk.ele.ele_comm:ELE消息 0x92800000 0x30000 0602971788000000 (自启动以来已过去 245 毫秒,ele_comm.py:502) 跟踪:spsdk.uboot.uboot:Uboot写入 -> ele_message 0x92800000 0x30000 0602971788000000 (自开始以来耗时 246 毫秒, __init__ .py:50) 调试:spsdk.uboot.uboot:Uboot读取直到 <- => (自启动以来 246 毫秒,uboot.py:271) 调试:spsdk.ele.ele_comm:原始ELE消息输出: ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (自启动以来 256 毫秒,ele_comm.py:422) 调试:spsdk.ele.ele_comm:已剥离输出:060497e1d600000000000000(自启动以来耗时 256 毫秒,ele_comm.py:460) 调试:spsdk.apps.utils.utils:SPSDK:响应中的消息大小无效:0x4(自启动以来耗时 257 毫秒,utils.py:182) 回溯(最近一次调用): 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py”,第 172 行,包装纸 retval = function(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”,在 safe_main 函数的第 2189 行 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 1631 行,在__call__ 返回 self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 1552 行,主线 rv = self.invoke(ctx) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 2032 行,在 invoke 中 返回 _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 1415 行,在 invoke 中 返回 ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 910 行,在 invoke 中 返回回调函数(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py”,第 46 行,在 new_func 中 返回 f(get_current_context().obj, *args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”,第 575 行,在 cmd_read_common_fuse 中 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”,第 588 行,在 ele_read_common_fuse 中 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py”,第 519 行,在 send_message 函数中 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”,第 1235 行,在 decode_response 中 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”,第 346 行,在 decode_response 中 raise SPSDKParsingError(f"响应中的消息 SIZE 无效:{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 ``` 注:我使用的是 `SPSDK 3.11.0` 我已在 SPSDK 的 GitHub 页面上创建了一个 issue: https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 非常感谢您的帮助。 谢谢! BR, Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 嗨joanxie 我使用的是 Linux 电路板支持包 版本 LF6.18.20_2.0.0 (yocto wrynose) 以下是 nxpele get-info 的输出结果 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 请问您执行此命令时使用的是哪个 EL 固件版本?让我再确认一下。 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 我重现了这个问题,并检查了内部数据库,确认这是一个已存在的问题,将在 spsdk 3.12.0 中修复。
記事全体を表示
S32K3x4EVB-T172 PIL通信エラー/タイムアウト(MBDT S32K3xx 1.4.0使用時) こんにちは、 MATLAB 2023a上で、MBDT S32K3xx (v1.4.0)を使用してPIL S32CTのサンプルを実行してみました。私のセットアップは、S32K3x4EVB-T172をオンボードのOpenSDAポートに接続しています。 試み1(OpenSDA COM): 生成されたターゲットモデルのフラッシュは成功しますが、PIL実行はすぐに以下のエラーで失敗します。 「通信チャネルが開かれませんでした」(添付のエラーメッセージのスクリーンショット参照) 試み2(外部USB2シリアルコンバータ) OpenSDAポートはフラッシュ用に繋いだままにしつつ、外部USB2SirealコネクタをJ44(1からTX、2からRX)に接続してPIL通信を行い、ハードウェア設定でCOMポートを更新しました。モデルは正常にフラッシュしますが、実行時にタイムアウトするとエラーがあります。 エラー:rtiostreamインターフェースからのデータ受信に10秒のタイムアウトが超過しました。この通信障害には複数の原因が考えられます。 あなたは以下のことをすべきです: (a) ターゲットハードウェア構成が正しいか、例えばバイトの順序が正しいかを確認します。 (b) ターゲットアプリケーションがターゲットハードウェア上で動作していることを確認。 (c) アプリケーションの実行時障害(例:例外で割り算、誤ったカスタムコード統合など)の可能性を考慮します。 注(c):実行時の失敗の原因を特定するために、シグナルハンドラとデバッグをサポートするSILの使用を検討してください。 解決策が見つからない場合は、rtw.connectivity.RtIOStreamHostCommunicatorのsetTimeoutRecvSecs方法を使ってタイムアウト値を増加させることを検討してください。   質問: 1.S32K3x4EVB-T172ボードはPIL用に外部USB2Serialコンバータが必要ですか?それとも内蔵のOpenSDAポート経由でPILを動かせますか? 2. 外部USB-シリアル変換が必要な場合、想定されるハードウェアUART構成は具体的にどのようなものですか? 3. 何か設定が抜けているのでしょうか? どんなアドバイスでも大変ありがたく思います! Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 こんにちは、 @PruthviB さん、 さらに調査する前に、なぜ MBDT S32K3xx v1.4.0を使っているのか、もう少し詳しく教えていただけますか?最新のリリースはv1.8.0で、いくつかの修正と改善が含まれています。まずはバージョン1.8.0にアップグレードして、問題が再現するかどうかを確認することをお勧めします。 あなたの構成についてですが、S32K3X4EVB-T172のPIL通信には外部のUSB-シリアル変換器は必須ではありません。オンボードの OpenSDAインターフェースはすでにホスト-ターゲット通信に使われるターゲットUARTへのアクセスを提供しているため、同じUSB接続でプログラミングとPIL通信の両方に使用できます。 OpenSDAはUARTピンに直接アクセスできるため、追加のUSBからシリアルアダプターへの接続は一般的に不要であり、複数のシリアルインターフェースが同時に動作している場合には設定競合を引き起こすことさえあります。 以下のような例を試してみていただけますか: MBDT S32K3xx v1.8.0 オンボードのOpenSDA USB接続のみ ハードウェア設定で選択された、OpenSDAによって公開されるCOMポート よろしくお願いします、 ドラゴス Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 やあ、 @dragostoma OpenSDAのオンボードインターフェースに関するご案内ありがとうございます。 バージョンに関しては、MBDT for BMSではMBDT v1.4.0が推奨バージョンでした。v1.4.0でのPILシミュレーションの実行についてのガイダンスを教えていただけますか? よろしくお願いいたします。 プルートヴィ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 こんにちは、 @PruthviB さん、 確かに、おっしゃる通りです。BMS Toolboxには、S32K3 Toolboxバージョン1.4.0が必要です。最初の議論ではBMSツールボックスについて言及されていなかったので、問題は古いバージョンのS32K3ツールボックスを使用していることに関連していると考えました。 バージョン1.4.0におけるPILシミュレーションに関しては、ワークフローに変更はありません。ツールボックスに付属する例モデルは、 LPUARTインスタンスを使用し、そのRXおよびTX信号がOpenSDAインターフェースを通じてルーティングされるように設定されています。専用の USBからシリアルコンバータを使用する場合は、別のLPUARTインスタンスを設定し、コネクテッドする受信および送信ピンを割り当てる必要があります。 要約すると: OpenSDAインターフェースの使用:ツールボックスに付属する例モデルは、追加の修正なしで動作するはずです。必要なLPUARTインスタンスと関連するRX/TXピンは既に設定済みです。 専用のUSBからシリアルコンバータを使用する場合:コンバーターは対象機器の特定のRXピンおよびTXピンに接続する必要があります。したがって、これらのピンは構成され、利用可能なLPUARTインスタンスにマッピングされる必要があり、それに伴いプロジェクト構成も更新する必要があります。 USB2Serialコンバーターを使用する際は、正しいCOMポートを使用し、J44のRXピンとTXピンが設定されているか確認してください。 どのように機能するか教えてください。 ドラゴス
記事全体を表示
Audifort Review: Does It Really Stop Tinnitus Overnight? Audifort Review: Does It Really Stop Tinnitus Overnight? If you are dealing with a non-stop ringing, buzzing, or clicking sound in your ears every single day, you know how desperate the search for relief can get. When looking for solutions online, you may come across aggressive advertisements for liquid dietary drops like Audifort that imply instant results or overnight relief from tinnitus. The short answer is no: Audifort does NOT stop tinnitus overnight. No oral supplement or natural drop can instantly cure chronic tinnitus or rebuild damaged auditory nerves in 24 hours. However, that does not mean the formula is useless. When evaluated realistically as a natural dietary supplement rather than a miracle cure, Audifort provides supportive nutrients that nourish inner ear blood vessels and calm overactive nerve signals over time. In this Audifort review, we look beyond the sales marketing to analyze how the drops actually work, its core ingredients, realistic expectation timelines, potential side effects, and how to avoid fake online listings.
記事全体を表示
i.MX95 Neutron:同じINT4 LLMで4問中1回答でNPU/CPUの不一致が発生します 概要 i.MX95 上で量子化された ONNX を 1 つ実行します。1 つは CPUExecutionProvider の下、もう 1 つは ニュートロン実行プロバイダー。2つの腕は同じ答えを出しません:2,466対 選択式問題では25.7%が異なる答えを返します(MMLUでは43.6%)。無料で 世代ごとに同じことが起こります - MMLU プロンプトでは、19 世代のうち 13 世代で 異なる回答の手紙。 これは言葉遣いの違いではありません。それはモデルが答える内容の違いです。一方、総合的なベンチマーク精度はわずか-1.8ポイントの変動にとどまった。 私たちは、Neutronランタイムが数値的に何をして生成するかを理解したいのです この大きさが予想されるかどうかも重要です。 設定 あなたの側で再現可能:モデルは表2からUG10166、量子化は 自分だけのレシピ、修正なし。 - ボード:i.MX95 19x19 EVK(IMX95LPD5EVK-19)、LPDDR5 - BSP: LF6.18.2_1.0.0、デバイスツリー imx95-19x19-evk-neutron.dtb - ランタイム:BSP + NeutronExecutionProviderからのONNX Runtime 1.22.0 - Neutron コンバータ:3.1.3 - モデル:meta-llama/Llama-3.2-1B-Instruct - 量子化:NXP/eiq-olive rev aae820e、 例/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 変換:convert_ort_models_to_neutron.py、CPU Armのモデルに適用されます。onnx - 環境: NEUTRON_CMA_512SLOTS=6 両方のArmは1つの量子化されたモデルから来ています。NPUアームはそのモデルを通過させるものです convert_ort_models_to_neutron.py。ソースのSHA-256を記録します - グラフ と 外部重み - 換算時に測定し、測定のたびに再確認します。 2回目の量子化実行や2回目のエクスポートはありません。 私たちが観察すること 1.4つの項目のうち1つは異なる回答が得られる。 MMLU、ARC-Challenge、PIQAからの2,466組のペアアイテム、0ショット、対数尤度でスコアリング 候補者の継続については、候補者ごとに1つのフォワード、生成なし、サンプリングなし。 各ベンチマークについて、ANSWER が変化した項目の割合、次に、 正確性が変更されました: - MMLU(4つの選択肢):回答変更率43.6%、正誤変更率27.1% - ARCチャレンジ(4つの選択肢):回答変更率21.3%、正誤変更率13.3% - PIQA(2つの選択肢):回答変更率9.4%、正誤変更率9.4% - 合計:回答変更率25.7%、正誤変更率17.3% 2つの数字が異なるのは、変更の3分の1(634件中208件)が1つの間違いから移動しているためです。 別の間違った答えへの答え - 正確さを失わせる真の行動の変化 手つかず。PIQAはバイナリであるため、そのような盲点はなく、2つの数値は一致する。 その通り。 2. 自由生成の場合も同様で、答え自体が変わります。 プロンプト数50、貪欲解読、トークン数64。MMLUプロンプトでは期待される出力が始まります 回答文字を含んで、その答えは世代から直接読み取ることができます (n = 19): - 両Arm間で異なる回答文字:19件中13件 - CPUで正解:19中7 - Neutronで正解:19題中6題 - 両Armが間違っていて、異なる誤答が出る意見の相違:13回中6回 回答の3分の2が変わったが、点数はほぼ同じだった(7対6)。 サンプル数は少ないので、ここでは例として報告します。上記の2,466項目の測定結果 これは定量的なものです。 以下に、一字一句そのままの例を示します。プロンプトには 4 つの選択肢がリストされており、文字を求められ、 期待される答えは 😧 CPU: " A\n説明: 式 9(9m + 3t) は 81m + 27t と同等です。 正解はAです。 NPU:「C\n正解はCです。」 どちらも間違っているが、その間違い方は異なり、それを記録できるベンチマークスコアは存在しない。 3. 乖離は累積ではなく、最初のフォワードで発生します。 このレター形式では、最初に生成されたトークンが答えであり、生成の 60% が 既に違いが生じているのは、デコードを行う前の、プリフィルパスのみで生成されたトークンである。 ステップ。50のプロンプトすべてにおいて、乖離曲線は急激に上昇した後、平坦化する。84%は トークン4、トークン64による98%。これが初期差分の伝播の様子です 貪欲なデコードの場合、KVキャッシュを通じてエラーが蓄積されることはありません。 4. 集計精度はそれらすべてを隠してしまう。 CPUは50.28%、Neutronは48.50%、-1.78ポイント差、そして 3つのベンチマークは個別に重要です。634項目に限定して 意見は異なっています。CPUは37.1%の確率で正しかったのに対し、Neutronは30.1%、235%の確率で正解です。 決定された項目のうち191、すなわち対称ノイズが50/50となる場合、55/45です。 除外したもの - サイレントCPUフォールバック: ORTプロファイリングレポートでは、80/80 MatMulNBitsが NeutronExecutionProvider、CPU使用率0。部分的な配置はできません。 - 2つの異なるモデル:同じソースファイル、グラフのSHA-256および外部重み コンバージョン時に記録され、得点前に再確認されました。 - サンプリング: 全体を通して貪欲なデコード。温度、トップk、トップpは使用しません。 - 異なる入力:両方のアームが同じアイテムファイルを同じ順序で消費します。 同じ固定シードです。 - 成果物のスコアリング:ボードはトークンごとの対数確率のみを捉えます;すべての決定 ロジックはホスト側でオフラインで動作し、両アームで同じように動作します。 - NPUのラン・トゥ・ランノイズ:同じNeutronセッション内で同じ項目を再生すること ビット同一の対数確率が得られます。NPUアームは再現可能であり、その不一致 それはCPUに対してであり、自分自身に対してではありません。 私たちの質問 これはニュートロンSのINT4経路に期待される挙動でしょうか?もしそうなら、どのようにすべきでしょうか NPU上でのLLM展開を検証し、集計ベンチマーク精度を明確に示します 表面に浮かび上がらない? 私たちは欠陥を想定しているわけではありません。浮動小数点CPUカーネルと 整数のNPU経路は通常であり、どのくらいの大きさを考えているのか知りたいです 通常、そしてどの基準でNEUTRONへのLLMポートを受け入れますか?もし 回答の4分の1が変わるのは期待内であり、それは私たちにとって有益なことです 知っていて、それを中心に設計する。 Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 迅速なご回答ありがとうございます! DS Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM こんにちは、 @DamienSCHNEBELEN さん。 IMX95 NPUはmatmulしか動作できず、NPUでのLLMのパフォーマンスは実際には平均的なレベルです。したがって、あなたが観察した現象は予測可能な範囲内であり、NPU上でLLMモデルを動かすことは推奨しません。 B.R
記事全体を表示
i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, I am using an i.MX RT1064 controller and debugging/flashing through the PEmicro Multilink interface in MCUXpresso IDE. Occasionally, I encounter the attached "PEmicro Connection Assistant" error while attempting to connect to the target. The issue appears to occur randomly; I have not identified any specific software activity, code change, or hardware event that consistently triggers it. What I have observed is that when this error occurs, the controller's boot configuration appears to have changed unexpectedly. In this state, I am unable to flash or debug the device. The only way I have been able to recover is by restoring the boot configuration to its original settings - Internal Flash Mode, after which flashing and debugging work normally again. A few additional details: MCU: i.MX RT1064 Debug Probe: PEmicro Multilink Universal Rev E IDE: MCUXpresso IDE Has anyone encountered a similar issue? I would appreciate any guidance on: What could cause the boot configuration to change unexpectedly. Whether there are known scenarios in which the debugger or application code could affect the boot configuration. Recommended methods to prevent this from happening. Can the boot configuration be changed through software without manual change I've attached a screenshot of the error message for reference. Thank you. i.MXRT 106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, Could you help me with the following questions? Are you using a custom board or the EVK? What version of the SDK and IDE are you using? Have you burned any fuses? You mentioned that you need to restore the boot configuration to internal flash mode—what boot configuration are you currently using? Best Regards, Pablo Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly I am using a custom board, but this issue was also observed on the EVK. SDK Version : 26.03.00 IDE Version : 25.6.136 We haven't burned any fuse. We usually use Internal Boot mode to flash our code and normal operation, but it causes some unexpected issues randomly, so we change it to Serial Download Mode, erase the flash and then change it back to Internal Boot mode before flashing code again. Please find attached image for boot configuration info. Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi @Subhasri_S, The BOOT_MODE register is initialized by sampling the BOOT_MODE0 and BOOT_MODE1 inputs on the rising edge of POR_B. After these inputs are sampled, their subsequent state does not affect the contents of the internal BOOT_MODE register. If BT_FUSE_SEL = 0, the specific boot configuration parameters can be set using the GPIO pins instead of eFuses. Could you help me measure the BOOT_MODE and BT_CFG pins during reset when the issue occurs? Another possible conclusion for this issue is described in the following knowledge base article: Knowledge Base : RT board recovery for debugger connect issues "When the flash contains an app that is abnormal(access memory does not exist, memory is corrupted, misconfiguration of the clocks, etc.), it will cause the board to end up in an unknown state, then the debugger can’t take control over the core. But, when put the core in serial downloader mode, then it will put the core in a known state, this way, the debugger will be able to take control of the core. So, when meeting the debugger issues in the RT board, try to mass erase the external flash in serial download mode, then it will recover the board debugger to a normal situation." Best Regards, Pablo Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, please find the recorded BOOT_MODE and BOOT_CFG Pin values when the issue occurs.
記事全体を表示
minimal configuration to negotiate higher current limit on USB I have a device that can be powered over USB with an MCXN947 processor on it.  I don't currently have the USB configured, just pulling 5V.  However, I would like to raise the current limit which seems to default to 100mA. What's the minimal configuration I can do to raise the current limit?  In MCUXpresso config tools, I tried setting up USBFS.  It requires at least one interface, so I tried to set up DFU.  I managed to get things to build mostly, but the config tools generate a file timer_queue.c that defines a SysTick_Handler that conflicts with the FreeRTOS port.c SysTick_Handler. 1) Is there something better I can do to try to raise the current limit? 2) If setting up this DFU interface is as good as anything else, how should I resolve conflicts between autogenerated code and the FreeRTOS port? Re: minimal configuration to negotiate higher current limit on USB Hello @robert_hines  Yes, a USB device must declare its required power in the bMaxPower field during USB enumeration. To draw more than 100 mA, I recommend configuring your device as a USB HID or USB CDC device, as these are generally easier to implement than DFU.   Thank you.   BR Alice
記事全体を表示
针对 Android Automotive 16.0.0_1.3.0 的安全更新预编译版本,不会破坏内核/U-Boot 构建 您好, 我们使用的是NXP Android Automotive 16.0.0_1.3.0,内核版本为 6.12 ,并采用 NXP 官方文档中记录的预编译版本: platform/prebuilts/clang/host/linux-x86 66acdd82ee62e4aaa4248f03191c59dfed9db193 kernel/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 platform/prebuilts/rust 5156e7f81ae254c79ee736e44c960e75ad685c67 platform/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 以下是 NXP Android Automotive 用户指南中针对此版本列出的修订内容。 使用这些修订版本可以构建,但我们的容器漏洞扫描报告称,提供的 Android 预构建版本中存在几个高危和严重漏洞。 例如,Clang 预编译版本包含嵌入式 Go 标准库。对于 clang-r536225/bin/clang,扫描结果显示: 总计:22 高危:21 严重:1 Go 标准库版本:v1.23.2 示例:CVE-2025-68121 crypto/tls - 证书验证错误 同样的发现模式也出现在 clang++ 和 clang-tidy 中,以及嵌入的 Go 版本为 v1.23.4 的较新的 clang-r547379 二进制文件中。 NXP 锁定的内核/预编译/构建工具也包含受影响的 soong_zip 二进制文件,其 Go-stdlib 查找模式相同。 Rust 预编译版本中还包含对已发布的 Cargo 锁定文件的发现,例如: thin-vec 0.2.13 版本已修复 常见漏洞与后门-2026-6654 漏洞(已在 0.2.16 版本中修复);hashbrown 0.15.0 版本已修复 GHSA-wwq9-3cpr-mm53 漏洞(已在 0.15.1 版本中修复)。 我们不希望用任意更新的 AOSP 提交替换已记录的修订版本,因为这些预构建版本是 NXP 内核/U-Boot 构建环境的一部分,我们希望保持与Android Automotive 16.0.0_1.3.0 / 内核 6.12 的兼容性。 对于这些预构建版本,是否有 NXP 推荐的更新版本或已知兼容的提交 ID? 我们尤其需要以下方面的更新修订: platform/prebuilts/clang/host/linux-x86 kernel/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   NXP 或社区中的其他人是否已经更新了这些版本并验证了以下内容仍然有效? 理想情况下,我们也希望确认完整的 Android Automotive 版本仍然能够与更新后的预构建版本兼容。 我们更倾向于更新受影响的预构建版本,而不是永久压制网络安全漏洞。 我已附上失败的漏洞扫描日志供您参考。它包含了受影响的 Clang、内核构建工具和 Rust 预编译版本的完整调查结果,包括检测到的嵌入式版本和可用的修复版本。 谢谢。 Android Re: Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot bu 你好, 我正在查看您的问题,稍后会向您汇报进展。 此致问候
記事全体を表示
最小配置即可协商更高的 USB 限流 我有一个可以通过USB供电的设备,它搭载了MCXN947处理器。我目前还没有配置USB,只是直接取5V电源。但是,我想提高限流,它的默认值似乎是 100mA。 我只需做哪些最少的配置就能提高限流?我在MCUXpresso配置工具中尝试设置USBFS。它至少需要一个接口,所以我尝试设置DFU模式。大部分东西都编译成功了,但是配置工具生成了一个名为 timer_queue.c 的文件。它定义了一个与 FreeRTOS port.c 冲突的 SysTick_Handler。SysTick_Handler。 1)我还能做些什么来提高限流? 2) 如果设置此 DFU 接口与其他方法一样好,我应该如何解决自动生成的代码和 FreeRTOS 端口之间的冲突? Re: minimal configuration to negotiate higher current limit on USB 你好@robert_hines 是的,USB 设备必须在 USB 枚举期间在 bMaxPower 字段中声明其所需的功率。 如果要消耗超过 100 mA 的电流,我建议将设备配置为 USB HID 或 USB CDC 设备,因为这些通常比 DFU 更容易实现。   谢谢!   BR 爱丽丝
記事全体を表示
i.MX RT1064 - PEmicro Connection Assistant エラーおよび起動設定の予期しない変更 こんにちは、 i.MX RT1064コントローラーを使い、MCUXpresso IDEのPEmicro Multilinkインターフェースを通じてデバッグやフラッシュを行っています。 ターゲットへの接続を試みる際に、添付の「PEmicro Connection Assistant」エラーが発生することがあります。この問題はランダムに発生するようです。特定のソフトウェア活動、コード変更、ハードウェアイベント情報で継続的にトリガーされるものは特定していません。 私が観察したのは、このエラーが起こると、コントローラーの 起動設定が予期せず変更されているように見えることです。この状態では、デバイスのフラッシュやデバッグを行うことができません。唯一回復できた方法は、起動設定を元の設定(内部フラッシュモード)に戻すことで、その後はフラッシュやデバッグが正常に動作します。 追加情報: MCU:i.MX RT1064 デバッグプローブ: PEmicro Multilink Universal Rev E IDE:MCUXpresso IDE 同様の問題に遭遇した方はいらっしゃいますか? 以下の点についてご助言いただければ幸いです。 なぜ起動設定が予期せず変わるのでしょうか。 デバッガやアプリケーションコードがブート設定に影響を与える既知のシナリオがあるかどうか。 これを防ぐための推奨方法。 CAN 手動変更なしでソフトウェアで起動設定を変更することはできますか 参考までに、エラーメッセージのスクリーンショットを添付しました。 よろしくお願いします。 i.MXRT 106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly こんにちは、 以下の質問に答えてもらえますか? カスタムボードを使用していますか、それともEVKを使用していますか? SDKとIDEのバージョンは何を使っていますか? ヒューズを焼いてしまったことはありますか? 起動設定を内部フラッシュモードに復元する必要があるとおっしゃっていましたが、現在どのブート設定を使っていますか? よろしくお願いします、 パブロ Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 私はカスタムボードを使用していますが、この問題はEVKでも確認されています。 SDK バージョン : 26.03.00 IDEバージョン:25.6.136 ヒューズは一つも切っていない。 通常は内部ブートモードでコードをフラッシュし、通常の動作をしますが、予期せぬ問題がランダムに起こるため、シリアルダウンロードモードに変え、フラッシュを消去してから再び内部ブートモードに戻してから再度コードをフラッシュします。 ブート設定情報については、添付画像をご覧ください。 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly こんにちは、 @Subhasri_S さん。 BOOT_MODEレジスタは、POR_Bの立ち上がりエッジでBOOT_MODE0とBOOT_MODE1の入力をサンプリングすることによって初期化されます。これらの入力がサンプリングされた後、その後の状態は内部のBOOT_MODEレジスタの内容に影響を与えません。 BT_FUSE_SEL = 0の場合、特定のブート設定パラメータはeFuseの代わりにGPIOピンで設定できます。 問題が起きたときにリセット時にBOOT_MODEとBT_CFGピンの測定を手伝ってもらえますか? この問題に関する別の可能性のある結論については、以下のナレッジベース記事に記載されています。 ナレッジベース:デバッガー接続の問題に対するRTボードの復旧 「フラッシュに異常なアプリ(アクセスメモリが存在しない、メモリが破損している、クロックの誤設定など)が含まれていると、ボードが未知の状態に陥り、デバッガがコアを制御できなくなります。しかし、コアをシリアルダウンローダーモードにすると、コアは既知の状態になり、デバッガーがコアを制御できるようになります。 SO、RTボードでデバッガの問題が発生した場合は、シリアルダウンロードモードで外部フラッシュを一括消去してみてください。そうすればボードデバッガは通常の状態に復元されます。」 よろしくお願いします、 パブロ Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly こんにちは。問題が発生した際に記録されたBOOT_MODEとBOOT_CFGのピン値を確認してください。
記事全体を表示