Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
i.MX6SXレジスタプログラミング支援 重要:ご質問がある場合やDDRツールまたはサポート・ドキュメントについて問題を報告したい場合は、i.MXコミュニティでサポートチケットを作成してください。プライベート・メッセージやダイレクト・メールは常時チェックされず、返信されないことにご留意ください。 これは、MMDC初期化に関連するレジスタの詳細なプログラミング支援です。最後のシートは、ARM RealView ICEで使用するためのレジスタ設定をフォーマットします。DDRストレステスト用の実行可能なウィンドウでも使用できます。このプログラミング補助ツールは、NXP社内の検証ボードに使用されました。 i.MX6SoloX Re: i.MX6SX LPDDR2 レジスタプログラミング支援 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> レジスタ MMDC_MAARCR は通常、初期化スクリプトによってプログラムされることはありません。Freescale はデフォルト値のままにしておくことを推奨しています。 これは、このレジスタの一部のフィールドを変更することを決定したお客様へのアドバイスです。 ARCR_GUARDフィールドにバグが見つかりました。常にデフォルトの0x0値にプログラムされたままにしておく必要があります。異なる値にプログラムされた場合、動作は予測不可能です。
記事全体を表示
Switched Mode Power Supply Overview Reference Designs Block Diagram Recommended Products Overview NXP digital signal controllers provide a switched-mode power supply solution that maximizes efficiency while reducing system costs through bill-of-materials savings. Our solution dynamically compensates for system disadvantages such as component aging and operational variability due to changing load conditions. Reference Designs Product Name Link Features 3-Phase PMSM Control https://www.nxp.com/design/designs/3-phase-pmsm-control:PERMANENT-MAGNET-MOTOR The 3-Phase Permanent Magnet Synchronous (PMSM) Motor Control Reference Design is based on Kinetis V Series MCUs and intended to provide the example for 3-phase sensorless PMSM motor control solutions. The Reference design utilizes a closed-loop field-oriented vector speed (FOC) control mechanism. KV Series Full-Bridge DC-DC Switch Mode Power Supply (SMPS) https://www.nxp.com/design/designs/kv-series-full-bridge-dc-dc-switch-mode-power-supply-smps:FULL-BRIDGE-SMPS  Full Bridge DC-DC Switch Mode Power Supply Block Diagram Recommended Products Category Products Features DSC Kinetis® V Series: Real-time Motor Control & Power Conversion MCUs based on Arm® Cortex®-M0+/M4/M7 | NXP  Kinetis V Series MCUs are based upon the Arm Cortex-M0+, Cortex-M4, and Cortex-M7 cores and are designed for a wide range of BLDC, PMSM, and ACIM motor control and digital power conversion applications. Temperature Sensor I²C Digital Temperature/Voltage Sensors | NXP  NXP I2C Temperature/Voltage monitors offer best-in-industry precision to fit any thermal management need. Block Diagrams Industrial
記事全体を表示
i.MX 8/8X/8XLite - LPDDR4 and DDR3L memory compatibility guide The purpose of this document is to provide supportive information for selection of suitable LPDDR4 and DDR3L devices that are supported by i.MX 8/8X/8XLite family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the respective memory vendor, the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the respective NXP i.MX 8 Hardware Developer's Guide available on NXP.com The i.MX8/8X/8XL Reference manuals declare that there are 16GB allocated for the DDR. Please note that this is only the address space, which is reserved for the DDR memory in the memory map. This specification does not guarantee that the entire region can be utilized as the maximum achievable densities listed below in the tables are restricted mainly by the addressing capabilities of the DDR controller, width of the data bus and other implementation-specific parameters as well as availability of supported devices on the market. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QM/8QP 29x29 mm 32-bit (per controller) 32Gb/4GB (per controller) dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 21x21 mm 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 17x17 mm 16-bit 16Gb/2GB dual rank, single-channel  device with 16-row addresses (R0-R15) 1, 2, 3, 4, 9 i.MX 8XLite 15x15 mm 16-bit 32Gb/4GB dual rank, single channel  device with 17-row addresses (R0-R16) 1, 2, 3, 9 LPDDR4 - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 8QM/8QP 24Gb/3GB (per controller) Micron MT53B768M32D4NQ-062 AIT:B   12, 13 32Gb/4GB (per controller)  Samsung K4FBE3D4HB-KHCL  10, 11 32Gb/4GB (per controller) Micron MT53E1G32D2FW-046 AUT:B (Z42M) 10, 11 32Gb/4GB (per controller) Micron MT53D1024M32D4DT-046 AAT:D   12 16Gb/2GB (per controller) Micron MT53D512M32D2DS-046 WT:D  10, 12 16Gb/2GB (per controller) Nanya NT6AN512T32AC-J1J  10, 11 16Gb/2GB (per controller) Nanya NT6AN512T32AC-J1H  10, 11 32Gb/4GB (per controller) Nanya NT6AN1024F32AC-J2J  10, 11 32Gb/4GB (per controller) Nanya NT6AN1024F32AC-J2H  10, 11 i.MX 8QXP/8DXP 24Gb/3GB Micron MT53B768M32D4NQ-062 AIT:B   12, 13 32Gb/4GB Nanya NT6AN1024F32AC-J2J  10, 11 32Gb/4GB Nanya NT6AN1024F32AC-J2H  10, 11 16Gb/2GB Nanya NT6AN512T32AC-J2J  10, 11 16Gb/2GB Nanya NT6AN512T32AC-J2H  10, 11 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D   11 i.MX 8XLite 8Gb/1GB Micron MT53D512M16D1DS 046 AAT ES:D & Z9XGG   12 12Gb/1.5GB Micron MT53E768M16D1ZW-046 AAT:C 10, 11, 13 4Gb/0.5GB Samsung K4F4E164HD-THCL  10, 11 8Gb/1GB ISSI IS43LQ16512A-053BLI 10, 11 8Gb/1GB Nanya NT6AN512M16AV-J1I  10, 11 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX8QM/8QP, i.MX8QXP/8DXP The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. The device only supports the LPDDR4X mode.    DDR3L - maximum supported densities SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QXP/8DXP 21x21 mm 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 6 i.MX 8QXP/8DXP 17x17 mm 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 7 i.MX 8XLite 15x15 mm 16-bit 16Gb/2GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 8 DDR3L - list of validated memories The validation process is an ongoing effort -  updates of the table are expected. SoC Density Memory Vendor Validated Mamory Part#  Notes i.MX 8QXP/8DXP 8Gb/1GB Micron 2x MT41K256M16TW-093 IT:P 12 i.MX 8XLite 4Gb/512MB Micron MT41K256M16TW-093 IT:P 12 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD209-4A. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chip to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the SoCs.  Note 5: The numbers are based purely on the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD79-3E/JESD79-3F. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 6: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select, or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that this number of discrete devices significantly exceeds the number of devices used on the validation board (2 discrete devices, not taking into account the device used for ECC) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies (x16 8Gb devices with 16-row addresses and 10 column addresses assumed instead of x8 devices in such case). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note that the first option exceeds the number of devices used on the validation board (2 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis, hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies. Note 8: The density can be achieved by connecting 2 single rank discrete devices with one 8Gb die each to the i.MX. 8XLite supports only one chip select for DDR3L therefore, dual-rank systems are not supported. Note 9: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (2025). Note 10: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 11: Part is active. Reviewed Aug 2025 Note 12: Part is being End Of Life'd (EoL) by Vendor or obsolete. Note 13: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Additional Links i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide 
記事全体を表示
FLEXCAN EDMA - 接收 CAN 消息突发时出现 ACK 错误 在 i.MXRT1176 上,我们使用 FLEXCAN 和 EDMA。(SDK 26.03) 我们定义了 DMA 传输完成的回调函数。 这是我们的流程: 1.调用 ` FLEXCAN_TransferReceiveFifoEDMA()` 开始传输。 2. DMA 传输完成后,调用用户定义的回调函数。 3. 从 DMA 缓冲区复制数据,并调用 `FLEXCAN_TransferReceiveFifoEDMA()` 继续接收消息。 4. 重复步骤 2-4 我们注意到,当我们从另一个节点以突发方式发送消息,且帧间间隔仅为最小值时,ACK 错误的数量会增加——iMX 无法确认消息。 从流程来看,每次 DMA 传输完成回调时,FLEXCAN 上的 DMA 都会被禁用。当调用 `FLEXCAN_TransferReceiveFifoEDMA()` 时,DMA 功能会重新启用。这可以通过调用 ` FLEXCAN_EnableRxFifoDMA()` 来实现。启用/禁用 DMA 会更新 FLEXCAN 的 MCR 寄存器中的 DMA 位,并且只能在冻结模式下进行。由于我们以突发方式接收消息,因此当 FLEXCAN 进入冻结模式时,可能正在进行传输,导致它无法确认接收到的消息。   我们确认,移除对 `FLEXCAN_EnableRxFifoDMA()` 的调用可以消除所有 ACK 错误,但同时也会丢弃一些消息。此外,我们还尝试拉开消息之间的间隔,这样也消除了 ACK 错误。请问这是否确实是实现方面的问题,或者我们是否应该采用不同的架构方式? Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages 嗨@r-uv , 感谢您提供的详细分析。您的观察结果与SDK的实现一致。 FLEXCAN_TransferReceiveFifoEDMA() 是一个有限长度的事务 API。每次 DMA 操作完成后,驱动程序会禁用 Rx FIFO DMA 请求,下一次调用时会再次启用该请求。由于更改 MCR[DMA] 需要冻结模式,最小 IFS 流量中的下一帧可能在 FlexCAN 恢复正常模式之前到达,从而导致 ACK 丢失。 这也解释了为什么移除重复的 DMA 启用/禁用操作可以消除 ACK 错误,但仍然会导致丢帧:与冻结相关的 ACK 间隙被消除,但 eDMA 传输没有持续重新开始。 对于连续突发流量,我们建议保持 Rx FIFO DMA 请求启用,并使用硬件链式乒乓/分散聚集 TCD,以便自动激活下一个缓冲区。这需要连续的 DMA 接收路径,而不是反复重新启动 FLEXCAN_TransferReceiveFifoEDMA()。 此致, 加文 Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages 谢谢你的回复。SDK 是否有计划添加此功能的支持?是采用基于连续DMA的实现方式,还是仅仅采用当前的事务性API实现方式?
記事全体を表示
S32K3 ADC 外部チャネルの利用 こんにちは。NXPチーム S32K3 ADCの外部チャネルの使い方 . Re: S32K3 ADC Use of external channels こんにちは、 @VaneBさん これに関して、追加の質問があります。 もし私のデザインにマルチマックスがなくても、例えばセンサ1にADC1_X[0]、センサ2にADC1_X[1]、そしてADC1_Xセンサ3にだけ使いたい場合は、MAピンをGPIO出力ピンなど他の用途で再利用してLEDを駆動することは可能でしょうか? 私のデザインはs32k344をベースにしています Re: S32K3 ADC Use of external channels NPXチームの皆様、こんにちは。 このトピックに関連して、以下の図のようなSCHを実装することが可能かどうか確認していただけますか? サポートありがとうございます。 Re: S32K3 ADC Use of external channels @VaneB ご協力いただき、誠にありがとうございました。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin 各ADCは外部アナログ多重化器の8チャネル中1チャネルを選択するために使う3つの外部デコード信号(MA)を提供し、最大4つのマルチプレクサを設置して32の外部チャネルを接続できます。つまり、これら4つのマルチプレクサは同じMA信号を共有します。 ADCは変換対象の現在のチャネルに基づき、これらの外部アナログ多重化器を制御するよう自動設定します。マスクレジスタのビットに応じて、対応する「X」ピンがサンプリングされ、その結果が「MA」と「X」の組み合わせに対応する場所に格納されます。 当社の開発ボードには外部アナログ多重化装置が設計されていないため、そのような例は実装されていません。 Re: S32K3 ADC Use of external channels こんにちは。ヴェインB あなたのプロンプトによると、RTDで外部チャネルADCを使った例が見つかりません。もし対応するルーティンがあれば、ぜひ送っていただけると嬉しいです。どうもありがとうございます。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin RTDで役立つかもしれないADCの実装例が見つかります。 BR VaneB
記事全体を表示
kw47 lpuart 您好: 根据官方例程 kw47loc_wireless_uart_freertos 修改并验证串行通信。仅修改 Uart_RxCallBack 和波特率。修改内容如下: 为了方便测试,目前每次通过串口发送 20 字节。测试发现,当波特率低于 256000 时,接收和发送均无问题。当波特率设置为 460800 或更高时,kw47 发送正常,但在接收过程中会发生丢包。 请问您能否帮我检查一下我的使用方法是否正确,并给我一些指导? 另外,为什么 sdk_26_03_00 中没有 kw47loc_freertos_lpuart_cm33_core0 例程? 谢谢!
記事全体を表示
2026年にAdopt Meのペットを無料で即座に入手するトップ10の方法 Robloxの「Adopt Me」をプレイしたことがある人なら、レア、レジェンダリー、ウルトラレアのペットを集めるのがどれほどエキサイティングなことか、既にご存知でしょう。ドラゴンやユニコーンからユニークなイベントペットまで、強力なペットコレクションを作ることはゲームの最も楽しい部分の一つです。しかし、誰もがRobuxを使ってインベントリを拡張したいわけではない。朗報です。実際のお金を使わずにAdopt Meのペットを無料で入手する合法的な方法がいくつかあります。 ➤➤ ここをクリックして このガイドでは、Adopt Meでペットを無料で入手するためのトップ10の方法を紹介し、安全かつ効率的にコレクションを増やすお手伝いをします。 1. 毎日ログイン報酬を完了する Adopt Meで無料のペットを手に入れる最も簡単な方法の一つは、毎日ゲームにログインすることです。Adopt Meでは、アクティブなプレイヤーに、ゲーム内通貨(Bucks)、アイテム、そして時折卵を入手できる機会などを含むデイリーボーナスが与えられます。 ログイン連続記録を長く維持すればするほど、より多くの報酬を受け取ることができます。継続が鍵であり、これらの報酬は時間をかけて孵化した貴重なペットになる卵の購入に役立ちます。 2. 無料の卵を孵化させる Adopt Meでは、卵がペットを入手する主な手段です。プレイヤーはゲームプレイで得たバックスを使って様々な卵を購入できます。最も人気のある選択肢には、ひび割れた卵、ペットの卵、ロイヤルエッグなどがあります。 日常の活動に参加し、お金を貯めることで、Robuxを使わずに卵を継続的に購入できます。卵を一つ開けるごとに、レアなペットや伝説のペットを無料で孵化させるチャンスが得られます。 3. 季節イベント情報への参加 Adopt Meは祝日や主要な祝日の際にイベント情報を頻繁に開催しています。これらのイベント情報では、Robuxで購入するのではなく、ゲームプレイチャレンジで獲得できる期間限定のペットが登場することが多いです。 ハロウィン、クリスマス、イースター、夏のイベント情報は、無料のAdopt Meペットを求めるプレイヤーの間で特に人気があります。イベント情報タスクをクリアしたり、イベント情報通貨を集めたりすると、イベント情報終了前に限定ペットをアンロックできます。 4. 他のプレイヤーと賢く取引する ペットのコレクションを増やすには、トレードが最も効果的な方法の一つです。伝説のペットがなくても、コモンペットとアンコモンペットを戦略的に取引することでステップアップできます。 重複しているペットを交換してくれるプレイヤーや、あなたが所有している特定のアイテムを必要としているプレイヤーを探しましょう。時間が経つにつれて、賢い取引は普段は手に入れにくいペットを手に入れる手助けをしてくれます。 必ず公式のゲーム内取引システムを利用し、ゲーム外で無料のペットを約束する詐欺には注意してください。 5. タスクを完了してバックスを獲得する Adopt Meでは、プレイヤーにBucks(ゲーム内通貨)が報酬として与えられる様々なアクティビティが用意されています。ペットへのご給餌、学校への通学、キャンプ、シャワー、その他の日常的な作業をこなすことで、卵子の購入に使える収入が生まれます。 活動的であればあるほど、バックスをより早く貯めることができます。多くの熟練プレイヤーは、定期的にタスクを完了するだけで数千ドルのバックスを獲得し、毎週複数の卵を孵化させている。 6. プレゼント企画に参加する 多くのAdopt Meコンテンツクリエイターは、YouTubeやDiscord、ソーシャルメディアなどのプラットフォームでプレゼント企画を開催しています。これらのプレゼント企画では、伝説のペット、珍しい卵、貴重なアイテムなどがよく登場します。 プレゼント企画に参加する前に、主催者が信頼できる人物であることを確認してください。正規のプレゼント企画では、パスワードやアカウント情報の入力は一切求められません。信頼できるプレゼント企画に参加することは、無料の「Adopt Me」ペットを手に入れる素晴らしい方法です。 7. ペットのレベルアップと成長 プレイヤーは、生まれたばかりのペットよりも、成長したペットを高く評価する傾向がある。タスクを通じてペットの年齢を上げることに時間を投資することで、取引価値を大幅に高めることができます。 成体になったペットは、交換条件によっては複数の若いペットに匹敵する価値があるかもしれない。この戦略を使えば、一般的なペットをより良い機会に変え、最終的にはRobuxを使わずに希少なペットを入手できます。 8. アクティブなAdopt Meコミュニティに参加する Adopt Meコミュニティは、無料のペットを求めるプレイヤーにとって貴重なリソースとなり得ます。Robloxグループ、Discordサーバー、ソーシャルメディアコミュニティでは、取引イベント情報やコンテスト、コミュニティのプレゼント企画がよく開催されています。 活発なコミュニティは、マーケットの価値、イベント情報、安全な取引慣行についても有益なアドバイスを提供します。これらのコミュニティに関わることで、普段なら逃すかもしれない機会につながります。 9.新しいアップデートを活用する Adopt Meのメジャーアップデートでは、毎回新しいコンテンツと機会が追加されます。新しい卵、ペット、イベント情報、ゲームプレイ機能などにより、アクティブなプレイヤーが貴重な報酬を獲得しやすくなることが多いです。 更新のお知らせに注意を払い、新しいコンテンツが公開されたらすぐに参加してください。早期に参加することで、ペットが希少で非常に人気が高まる前に手に入れる助けになることがあります。 10. ペットマネジメントの戦略を活用する ペットを効果的に管理することで、時間とともにより良いペットを迎える可能性が高まります。複数のペットを同時に育て、タスクを効率的に完了させ、可能な限りバックスを節約することに集中しましょう。 多くの成功したプレイヤーは、複数のペットを同時に世話したり、ファミリのゲームプレイ要素を組み合わせて収益を最大化するなどの代替戦略を用います。より良い資源マネジメントは、より多くの卵、孵化、そして最終的にはより多くの無料ペットをもたらします。 無料ペット詐欺を回避するためのヒント Adopt Meで無料のペットを探していると、すぐに伝説のペットを提供すると謳うウェブサイト、動画、または個人に出くわす可能性が高いでしょう。注意深く、以下のセーフティ対策を守ってください: Robloxのパスワードは絶対に他人に教えないでください。 無料のペットを入手できると謳うウェブサイトは避けてください。 公式のAdopt Meトレードシステムのみを使用してください。 参加する前に、プレゼント企画の主催者を確認してください。 Robloxアカウントで二要素認証を有効にしてください。 正当な無料ペットは、ゲームプレイ、取引、イベント情報、信頼できるコミュニティ活動を通じて得られることを忘れないでください。 まとめ Adopt Meで無料のペットを入手するのに、Robuxを使う必要はありません。毎日ログインし、タスクをこなし、イベント情報に参加し、卵を孵化させ、プレゼント企画に参加し、賢く取引することで、着実に素晴らしいペットコレクションを築くことができます。 最も成功したプレイヤーはこれらの方法をいくつか組み合わせ、ゲーム内で活動し続けます。時間をかけて、忍耐強く継続すれば、リアルマネーを使わずにレア、超レア、さらにはレジェンダリーのペットをアンロックできるようになります。 初めてペットを飼いたい初心者の方も、コレクションを増やしたいベテランの方も、Adopt Meで無料のペットを手に入れるためのこのトップ10の方法を使えば、お財布に負担をかけずにAdopt Meのすべてを楽しむことができます。
記事全体を表示
MPC5647 闪存无法访问 我们使用的是 MPC5647 设备。 我们使用Trace32,将一个应用程序编程写入了内部闪存区域。编程过程刚开始(或刚一完成),目标硬件的电源就被切断了。 此事件发生后,便无法再访问应用区域中的闪存。通过Trace32访问Flash时,内存内容显示为"????????" ,或者"FFFFFFFF" 。我们怀疑是在Flash编程操作尚未完全结束之前就切断了电源。 在此情况下,应用闪存区域将无法使用,且只能通过执行 AN4521_MPC56xx C90FL Flash Recovery.pdf 中所述的出厂恢复程序来恢复闪存。执行恢复操作后,闪存即可再次使用。 我们希望了解以下内容: 是什么原因导致了这种现象? 为什么在闪存编程过程中发生意外断电会导致无法访问该闪存块? 为什么不能直接对闪存进行重新编程呢? 为什么在重新对闪存进行编程之前,必须先执行恢复/出厂初始化操作? 这是否与无效的 ECC 状态、不完整的擦除操作,还是其他闪存控制器内部状况有关? 如果能对Flash的内部工作原理进行详细说明,我们将不胜感激。 Re: MPC5647 Flash Inaccessibility 你好 此事件发生后,便无法再访问应用区域中的闪存。通过Trace32访问Flash时,内存内容显示为"????????" ,或者"FFFFFFFF" 。我们怀疑是在Flash编程操作尚未完全结束之前就切断了电源。 这表明闪存可能已损坏。 在此情况下,应用闪存区域将无法使用,且只能通过执行 AN4521_MPC56xx C90FL Flash Recovery.pdf 中所述的出厂恢复程序来恢复闪存。执行恢复操作后,闪存即可再次使用。 这肯定是编程过程中因断电导致的闪存损坏。闪存中存在大量ECC错误,这就是为什么你在跟踪信息中看到“?????”的原因。 为什么在闪存编程过程中发生意外断电会导致无法访问该闪存块? 简而言之,如果您未完成编程或进行了擦除,闪存数据将出现不匹配,并伴随ECC症状。 为什么在重新对闪存进行编程之前,必须先执行恢复/出厂初始化操作? 标准程序命令期望获得一个已彻底擦除的块 中断后: 控制器检测到无效状态 → 拒绝命令 因此: 擦除/编程序列始终无法正确启动 访问可能被阻止或返回虚假数据 这是否与无效的 ECC 状态、不完整的擦除操作,还是其他闪存控制器内部状况有关? 因电源中断而进入ECC状态。 顺祝商祺! Peter
記事全体を表示
S32K312 — PTB2 上的外部中断 (EIRQ_10) 未触发 你好,恩智浦社区、 我正在使用 RTD 4.0.0(AUTOSAR 4.7)和 S32 Design Studio 3.6.6 在 S32K312(100 引脚 HDQFP)上实现外部中断、目标 PTB2(引脚 48)→EIRQ_10。我参考了使用 PTB26 → EIRQ_13 的 NXP 社区示例 (S32K312_EIRQ_interrupt),并将其改编为 PTB2。但是,中断回调永远不会被触发。 我验证了 IOMUX 表 (S32K312_IOMUX.xlsx)并确认 PTB2 通过 SIUL_IMCR538(索引 26)正确映射到 EIRQ[10],SSS=0001(ALT1)--因此引脚路由值似乎是正确的。 如能提供在 100 引脚 S32K312 上使用 PTB2 (EIRQ_10) 的指导或工作示例,将不胜感激。 谢谢! Re: S32K312 – External Interrupt (EIRQ_10) on PTB2 Not Triggering 你好 我已在下面的主题中作了回复: https://community.nxp.com/t5/S32K/S32K312-External-Interrupt-EIRQ-10-on-PTB2-Not-Triggering/td-p/2376810 顺祝商祺! Peter Re: S32K312 – External Interrupt (EIRQ_10) on PTB2 Not Triggering 你好,彼得、 感谢您的建议。 我检查了推荐的寄存器,得到了以下运行时值: DISR0 = 0 DIRER0 = 1024 (0x00000400),启用第 10 位 IREER0 = 1024 (0x00000400),启用第 10 位 IFEER0 = 0(上升沿配置) imcr[26] = 1 (备选 1) NVIC ISER1 = 4194304 (0x00400000),对应 IRQ54 (SIUL_IRQ1),启用第 22 位 我还验证了硬件输入路径: PTB2 配置为 EIRQ10。 读取 PTB2 输入状态正常。 当外部信号施加到 PTB2 时,该引脚读取逻辑 "1"。 信号移除后,引脚读数为逻辑 "0"。 然而,尽管输入状态发生了正确的变化: DISR0 位 10 永远不会被设置。 未输入 SIUL_IRQ1 ISR。 未执行已注册的回调函数。 从这些观察结果来看 物理输入信号正确到达 PTB2。 IMCR 路由已按预期配置。 中断使能寄存器配置正确。 NVIC 启用位被设置。 但是,EIRQ10 事件不会生成 SIUL2 中断状态标志(DISR0 第 10 位仍为 0),因此 ISR 从未被调用。 你能否告知接下来应该检查哪些额外的 SIUL2/EIRQ 寄存器,或者是否有任何已知的 S32K312 上的 PTB2 → EIRQ10 要求,即使引脚输入状态正确变化,也可能会阻止 DISR0 断言? 此外,我使用的是S32K312(100 引脚 HDQFP),使用 RTD 4.0.0(AUTOSAR 4.7)和 S32 Design Studio 3.6.6。能否请您确认是否存在任何设备特定的限制、SIUL2 路由要求、焊盘特性、特定封装注意事项或 PTB2 → EIRQ10 的 RTD 配置依赖关系? 由于引脚输入状态变化正确,但 DISR0 第 10 位从未被置位,也从未进入 ISR,因此除了标准端口、ICU 和 NVIC 配置外,我还希望获得有关 S32K312 特定检查的指导。 致以最诚挚的问候, Esakki
記事全体を表示
SJA1110A DSA 上电:100BASE-TX TX 故障和 T1 链路培训问题 你好 我正在使用 Linux DSA 通过 SPI 将一个 SJA1110AEL 交换机连接到 Microchip PolarFire SoC 上 sja1105驱动程序,通过 SPI 将 SJA1110AEL 开关连接到 Microchip PolarFire SoC: https://github.com/linux4microchip/linux/tree/linux-6.12-mchp%2Bfpga/drivers/net/dsa/sja1105 交换机配置为 SPI 启动模式(BOOT_OPTION=11),静态配置上传看起来很成功。 [ 2.546758] sja1105 spi9.0: Probed switch chip: SJA1110A [ 2.546777] sja1105 spi9.0: max_xfer_len = 256 bytes [ 2.549576] sja1105 spi9.0: Config buffer length: 1776 bytes [ 2.549605] sja1105 spi9.0: Config buffer device_id at offset 0: 0x0f0300b7 [ 2.742531] sja1105 status decoded: CONFIGS=1 CRCCHKL=0 IDS=0 CRCCHKG=0 NSLOT=9 [ 2.742563] sja1105 spi9.0: sja1105_static_config_load done [ 2.742579] sja1105 spi9.0: sja1105_clocking done [ 2.742592] sja1105 spi9.0: sja1105_TAS and flower setup done [ 2.743823] sja1105 spi9.0: sja1105_ptp_clock_register done [ 2.888661] sja1105 spi9.0: sja1105_mdiobus_register done [ 2.888699] sja1105 spi9.0: sja1105_devlink_setup done [ 2.902778] sja1105 spi9.0: dsa_tag_8021q_register and rtnl_unlockdone [ 2.904141] sja1105 spi9.0: configuring for fixed/sgmii link mode [ 2.909745] sja1105 spi9.0: Link is Up - 1Gbps/Full - flow control off [ 2.964511] sja1105 spi9.0 rj45 (uninitialized): PHY [spi9.0-base-tx:01] driver [NXP CBTX (SJA1110)] (irq=POLL) [ 2.973125] sja1105 spi9.0 t1-1 (uninitialized): PHY [spi9.0-base-t1:01] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.976322] sja1105 spi9.0 t1-2 (uninitialized): PHY [spi9.0-base-t1:02] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.979382] sja1105 spi9.0 t1-3 (uninitialized): PHY [spi9.0-base-t1:03] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.982622] sja1105 spi9.0 t1-4 (uninitialized): PHY [spi9.0-base-t1:04] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.985855] sja1105 spi9.0 t1-5 (uninitialized): PHY [spi9.0-base-t1:05] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.989002] sja1105 spi9.0 t1-6 (uninitialized): PHY [spi9.0-base-t1:06] driver [Generic Clause 45 PHY] (irq=POLL) [ 2.991420] macb 20110000.ethernet eth0: entered promiscuous mode [ 2.991540] DSA: tree 0 setup [ 2.993156] clk: Disabling unused clocks ############################################## *************** FSW-PIXXEL *************** *************** IN_xPC *************** ############################################## # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever 2: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 4e:0a:f0:7b:bc:e0 brd ff:ff:ff:ff:ff:ff 3: can0: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 4: can1: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 5: eth0: mtu 1536 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 6: eth1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:04:a3:61:cc:6f brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: rj45@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 9: interswitch@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 10: epc2-uplink@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 11: t1-1@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 12: t1-2@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 13: t1-3@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 14: t1-4@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 15: t1-5@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff 16: t1-6@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 目前的观察结果: CPU 端口 (SGMII) 启动正常。 我可以从连接到 RJ45 100BASE-TX 端口的笔记本电脑接收 ARP 数据包。 板上的 tcpdump 确认来自笔记本电脑的 ARP 请求。 当从主板发送(ping/arping)时,笔记本电脑不会收到任何东西。 笔记本电脑 tcpdump 未显示来自主板的 RX 数据包。 我的问题是 要使 TX 流量在 SJA1110 DSA 端口上正常工作,是否需要任何额外的运行时 MAC 配置/转发/路由表设置? 是否可以预期 100BASE-T1 PHY 在此驱动程序树 中仅作为 通用条款 45 PHY 出现 ? 当前的 Linux 6.12 Microchip 树中是否缺少专用 BASE-T1 PHY 驱动程序? 为了进行测试,我尝试在两个 T1 端口之间进行直接环回 (T1-1<-> T1-2) 之间的直接环回,方法是连接:(TRX_1_P<->TRX_2_P 和 TRX_2_P<->TRX_2_N )。 SJA1110 BASE-T1 PHY 是否需要为链路训练进行明确的主/从配置? 8: rj45@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff inet6 fe80::5c78:8fff:fe24:8653/64 scope link proto kernel_ll valid_lft forever preferred_lft forever 11: t1-1@eth0: mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global t1-1 valid_lft forever preferred_lft forever 12: t1-2@eth0: mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 5e:78:8f:24:86:53 brd ff:ff:ff:ff:ff:ff inet 192.168.10.2/24 scope global t1-2 valid_lft forever preferred_lft forever [ 133.739306] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 133.739364] MACB : HWSTAMP check running [ 133.739414] MACB : HWSTAMP check passed found tsu_clk [ 133.741036] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. [ 133.742794] sja1105 spi9.0 t1-1: configuring for phy/internal link mode [ 149.008075] sja1105 spi9.0 t1-2: configuring for phy/internal link mode [ 543.849763] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 545.889486] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off   硬件表带配置: 全部 PHY_MS引脚均为低电平(从属模式)。 PHY_AUTO_MODE= 高 AUTO_POL_DET= 高电平 PHY 地址从 0x09. 没有 T1 链路的原因会不会是两个 PHY 都绑定为 SLAVE,因此没有用于链路训练的主时钟源? 有关以下方面的任何指导: 正确的 T1 启动、 主/从配置、 或预期 PHY 驱动程序支持 将不胜感激。 这是用于以太网交换机的 DTSI。 /* MAC0 : DSA master into SJA1110A SGMII4 */ &mac0 { /delete-property/ phy-handle; clocks = <&clkcfg CLK_MAC0>, <&clkcfg CLK_AHB>, <&fabric_fic3_clk>; clock-names = "pclk", "hclk", "tsu_clk"; phy-mode = "sgmii"; status = "okay"; dma-noncoherent; fixed-link { speed = <1000>; full-duplex; }; }; /* * SPI9: SJA1110A Host Access Port (HAP) * CS0 (reg=0) -> SS0_N -> Switch AP endpoint (DSA driver) * CS1 (reg=1) -> SS1_N -> Cortex-M7 uC endpoint (unused) * * BOOT_OPTION=11 (serial SPI boot): * SJA1110A waits for host config at power-on. * DSA driver sends static config tables at probe via CS0. * Cortex-M7 is disabled by driver : CS1/SS1 never used. * * SPI mode: CPOL=1 CPHA=0 (mode 2) : as per sja1105.yaml * SPI mode: CPOL=1 CPHA=1 (mode 3) : as per s32gxxxa-rdb.dtsi */ &spi9 { microchip,motorola-mode = <3>; /* mode 3: CPOL=1 CPHA=1 */ num-cs = <2>; status = "okay"; /* * SJA1110A : DSA switch (mainline driver) * reg=0 -> CS0 -> SS0_N -> switch AP endpoint * ethernet-switch@0 uses reg=<0> (SS0 = switch AP) * sja1110-uc@1 uses reg=<1> (SS1 = uC, disabled here) * * Port map * port@0 RevMII Cortex-M7 uC (disabled by driver) * port@1 100BASE-TX RJ45 diagnostic jack * port@2 RGMII2 inter-switch trunk -> SJA port2 * port@3 SGMII3 EPC-2 MAC1 relay uplink * port@4 SGMII4 EPC-1 MAC0 CPU port (this board) * Confirm is actual physical address needs to be added here * port@5 100BASE-T1 TRX_1 (PHY addr 9 on mdio@0) * port@6 100BASE-T1 TRX_2 (PHY addr 10 on mdio@0) * port@7 100BASE-T1 TRX_3 (PHY addr 11 on mdio@0) * port@8 100BASE-T1 TRX_4 (PHY addr 12 on mdio@0) * port@9 100BASE-T1 TRX_5 (PHY addr 13 on mdio@0) * port@a 100BASE-T1 TRX_6 (PHY addr 14 on mdio@0) */ sja1110a: ethernet-switch@0 { compatible = "nxp,sja1110a"; reg = <0>; spi-max-frequency = <1000000>; interrupt-parent = <&gpio8>; interrupts = <9 IRQ_TYPE_LEVEL_LOW>; mdios { #address-cells = <1>; #size-cells = <0>; mdio_t1: mdio@0 { compatible = "nxp,sja1110-base-t1-mdio"; reg = <0>; #address-cells = <1>; #size-cells = <0>; port5_base_t1_phy: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x01>; }; port6_base_t1_phy: ethernet-phy@2 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x02>; }; port7_base_t1_phy: ethernet-phy@3 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x03>; }; port8_base_t1_phy: ethernet-phy@4 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x04>; }; port9_base_t1_phy: ethernet-phy@5 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x05>; }; port10_base_t1_phy: ethernet-phy@6 { compatible = "ethernet-phy-ieee802.3-c45"; reg = <0x06>; }; }; mdio_tx: mdio@1 { compatible = "nxp,sja1110-base-tx-mdio"; reg = <1>; #address-cells = <1>; #size-cells = <0>; txphy1: ethernet-phy@1 { reg = <1>; }; }; }; ethernet-ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; status = "disabled"; }; /* ------------------------------------- * RJ45 diagnostic port * ------------------------------------- */ port@1 { reg = <1>; label = "rj45"; phy-mode = "internal"; phy-handle = <&txphy1>; }; port@2 { reg = <2>; label = "interswitch"; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; port@3 { reg = <3>; label = "epc2-uplink"; phy-mode = "sgmii"; fixed-link { speed = <1000>; full-duplex; }; }; /* ------------------------------------- * CPU port * MAC0 <-> SGMII4 <-> port4 * ------------------------------------- */ port@4 { reg = <4>; label = "cpu"; ethernet = <&mac0>; phy-mode = "sgmii"; fixed-link { speed = <1000>; full-duplex; }; }; port@5 { reg = <5>; label = "t1-1"; phy-mode = "internal"; phy-handle = <&port5_base_t1_phy>; }; port@6 { reg = <6>; label = "t1-2"; phy-mode = "internal"; phy-handle = <&port6_base_t1_phy>; }; port@7 { reg = <7>; label = "t1-3"; phy-mode = "internal"; phy-handle = <&port7_base_t1_phy>; }; port@8 { reg = <8>; label = "t1-4"; phy-mode = "internal"; phy-handle = <&port8_base_t1_phy>; }; port@9 { reg = <9>; label = "t1-5"; phy-mode = "internal"; phy-handle = <&port9_base_t1_phy>; }; port@a { reg = <10>; label = "t1-6"; phy-mode = "internal"; phy-handle = <&port10_base_t1_phy>; }; }; }; /* SPIDEV for testing SPI lines using CS1 lines*/ sja110_spidev: spidev@1 { compatible = "microchip,mpfs-spidev"; reg = <1>; status = "okay"; spi-max-frequency = <1000000>; }; }; -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 感谢您一次性分享所有细节。 请在下面找到您问题的答案。 Q1.要使 TX 流量在 SJA1110 DSA 端口上正常工作,是否需要任何额外的运行时 MAC 配置/转发/路由表设置? A1.是的,请见下文。 Q2.100BASE-T1 PHY 在此驱动程序树中是否只能作为通用第 45 条 PHY 出现?当前的 Linux 6.12 Microchip 树中是否缺少专用 BASE-T1 PHY 驱动程序? A2.A2. Q3.为进行测试,我尝试在两个 T1 端口(t1-1<-> t1-2)之间直接环回,方法是连接:(TRX_1_P<->TRX_2_P 和 TRX_2_P<->TRX_2_N )。 A3:是的,没错。 Q4.SJA1110 BASE-T1 PHY 是否需要为链路训练进行明确的主/从配置? A4.是的,100BASE-T1 需要明确的主/从设置。仅供参考,驱动器中的"AUTO" 选项通常意味着"按照引脚捆绑" 。 要实现有效链接,必须通过硬件捆绑或 PHY 配置,将一个 PHY 配置为 MASTER(主设备),另一个 PHY 配置为 SLAVE(从设备)。 根据日志和 DT,交换机初始化和 PHY 绑定看起来是正确的。 如果 Linux 中没有配置网桥,就会出现 RX 可以工作而 TX 不能工作的情况。在 DSA 中,CPU 端口和用户端口之间不会自动转发流量。 DSA 交换机的行为类似于硬件交换机,但除非显式创建了网桥或 VLAN 配置,否则 Linux 不会在端口之间启用转发功能。 请创建一个网桥,同时连接 CPU 端口(eth0)和用户端口(rj45): ip link set eth0 up ip link set rj45 up ip link add br0 type bridge ip link set br0 up ip link set eth0 master br0 ip link set rj45 master br0 ip addr add 192.168.1.2/24dev br0 顺祝商祺! 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 您好, 我试过做同样的事情,但仍然没有看到笔记本电脑从 板上收到任何数据包。以下是我遵循的具体步骤: ------------------- ip link set eth0 up ip link set rj45 up ip link add br0 type bridge ip link set br0 type bridge ip link set br0 up ip link set rj45 master br0 ip addr add 192.168.1.1/24dev br0 ping 192.168.1.2 ------------------- 为了提供更多信息:RJ45 连接器已返工,芯片 TX 对的 P/N 端口与 RJ45 连接错误,这也可能是造成问题的原因。但是,链接总是会出现。 有什么我遗漏的吗?我附上了与 ETH 和 PHY 相关的内核配置。请检查是否有遗漏。 # ------------------------------ # Networking / HSR / QoS / PTP # ------------------------------ CONFIG_HSR=y CONFIG_PTP_1588_CLOCK=y CONFIG_POSIX_TIMERS=y CONFIG_BONDING=y CONFIG_NET_SCHED=y CONFIG_NET_SCH_FIFO=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_FQ_CODEL=y CONFIG_NET_SCH_MQPRIO=y CONFIG_NET_SCH_ETF=y CONFIG_NET_SCH_TAPRIO=y CONFIG_NET_CLS=y CONFIG_NET_CLS_U32=y CONFIG_NET_ACT_MIRRED=y CONFIG_MACB_USE_HWSTAMP=y CONFIG_NETWORK_PHY_TIMESTAMPING=y # ----------------------------- # SJA1110 Ethernet Switch support # ----------------------------- CONFIG_PHYLINK=y CONFIG_PCS_MARVELL=y CONFIG_SWPHY=y CONFIG_BRIDGE_VLAN_FILTERING=y CONFIG_VLAN_8021Q=y CONFIG_NET_DSA=y CONFIG_NET_DSA_TAG_8021Q=y CONFIG_NET_DSA_SJA1105=y CONFIG_NET_DSA_SJA1105_PTP=y CONFIG_NET_DSA_SJA1105_TAS=y CONFIG_NET_SWITCHDEV=y CONFIG_NET_DSA_TAG_OCELOT_8021Q=y CONFIG_MDIO_BUS=y CONFIG_MDIO_DEVICE=y CONFIG_NET_SCH_CBS=y CONFIG_BRIDGE=y CONFIG_OF_MDIO=y CONFIG_MDIO_DEVRES=y CONFIG_NET_DSA_SJA1105_VL=y CONFIG_PHYLIB_10G=y # ----------------------------- # PHY support for direct ETH link (MAC0 - OBC) # Fixed link - no PHY driver needed for MAC0 # MAC1 - SJA1110 also uses fixed link to switch CPU port # ----------------------------- CONFIG_FIXED_PHY=y CONFIG_PHYLIB=y CONFIG_NXP_CBTX_PHY=y CONFIG_NXP_C45_TJA11XX_PHY=y CONFIG_NXP_TJA11XX_PHY=y CONFIG_MARVELL_88Q2XXX_PHY=y CONFIG_AQUANTIA_PHY=y CONFIG_MICREL_PHY=y 我还尝试用 T1-1 和 T1-2 进行 100BASE-T1 环回,将 T1-1 设置为 PHY_MS = 1(主站),T1-2 设置为 PHY_MS = 0(从站)。我调出了两个界面,但链接始终没有出现。这在意料之中吗?我错过了什么?环回是双绞线(P/N)上的简单有线连接。 ------------------- ip link set eth0 up ip link set rj45 up ip link set t1-1 up ip link set t1-2 up ------------------- Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 不知怎么的,你漏了一行: ip link set eth0 up ip link set rj45 up   ip link add br0 type bridge ip link set br0 up   ip link set eth0 master br0 ip link set rj45 master br0   ip addr add 192.168.1.1/24开发周期 内核配置似乎正确。 关于 T1 100BASE-T1 的简单布线连接应该可以正常工作,我一直使用这种连接方式。是否使用 PHY_ADDR* 引脚绑扎? 请分享: ethtool t1-1 ethtool t1-2 dmesg | grep -iE"t1-|phy|sja1105" 在链接启动之后 顺祝商祺! 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@PavelL, 感谢您的回答。 将 eth0 连接到 br0 后,当尝试连接 rj45 时,我看到如下错误。 # ip link set eth0 up [ 20.561460] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 20.561554] MACB : HWSTAMP check running # [ 20.561605] MACB : HWSTAMP check passed found tsu_clk [ 20.562612] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. ip link set rj45 up # [ 25.693665] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 27.746002] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off # ip link add br0 type bridge # ip link set br0 up # ip link set eth0 master br0 # [ 43.053547] br0: port 1(eth0) entered blocking state [ 43.053590] br0: port 1(eth0) entered disabled state [ 43.053666] macb 20110000.ethernet eth0: entered allmulticast mode ip link set rj45 master br0 [ 49.972011] br0: port 2(rj45) entered blocking state [ 49.972214] br0: port 2(rj45) entered disabled state [ 49.972288] sja1105 spi9.0 rj45: entered allmulticast mode RTNETLINK answer[ 50.005003] sja1105 spi9.0 rj45: left allmulticast mode s: Invalid argument 关于 T1 端口,请参见以下答复 # ip link set eth0 up [ 305.486294] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 305.486405] MACB : HWSTAMP check running [ 305.486456] MACB : HWSTAMP check passed found tsu_clk [ 305.487476] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. # ip link set rj45 up # [ 311.277622] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 313.313486] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off # ip link set t1-1 up # [ 326.282210] sja1105 spi9.0 t1-1: configuring for phy/internal link mode # ip link set t1-2 up [ 330.126681] sja1105 spi9.0 t1-2: configuring for phy/internal link mode # ethtool t1-1 Settings for t1-1: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Link detected: no # ethtool t1-2 Settings for t1-2: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Duplex: Full Port: MII PHYAD: 2 Transceiver: external Auto-negotiation: off Wake-on: d Link detected: no # [ 365.547745] power_supply bq34z100-0: driver failed to report `time_to_empty_avg' property: -22 dmesg | grep -iE "t1-|phy|sja1105" [ 2.250188] u-dma-buf udmabuf-ddr-c0: phys address = 0x0000000088000000 [ 2.995658] u-dma-buf udmabuf-ddr-nc0: phys address = 0x00000000c8000000 [ 3.012712] u-dma-buf udmabuf-ddr-nc-wcb0: phys address = 0x00000000d8000000 [ 3.081775] sja1105 spi9.0: Probed switch chip: SJA1110A [ 3.081796] sja1105 spi9.0: max_xfer_len = 256 bytes [ 3.233399] sja1105 spi9.0: Probed switch chip: SJA1110A [ 3.233418] sja1105 spi9.0: max_xfer_len = 256 bytes [ 3.236047] sja1105 spi9.0: Config buffer length: 1776 bytes [ 3.236072] sja1105 spi9.0: Config buffer device_id at offset 0: 0x0f0300b7 [ 3.429135] sja1105 status decoded: CONFIGS=1 CRCCHKL=0 IDS=0 CRCCHKG=0 NSLOT=5 [ 3.429165] sja1105 spi9.0: sja1105_static_config_load done [ 3.429181] sja1105 spi9.0: sja1105_clocking done [ 3.429194] sja1105 spi9.0: sja1105_TAS and flower setup done [ 3.430339] sja1105 spi9.0: sja1105_ptp_clock_register done [ 3.572901] sja1105 spi9.0: sja1105_mdiobus_register done [ 3.572938] sja1105 spi9.0: sja1105_devlink_setup done [ 3.586915] sja1105 spi9.0: dsa_tag_8021q_register and rtnl_unlockdone [ 3.588440] sja1105 spi9.0: configuring for fixed/sgmii link mode [ 3.593936] sja1105 spi9.0: Link is Up - 1Gbps/Full - flow control off [ 3.652480] sja1105 spi9.0 rj45 (uninitialized): PHY [spi9.0-base-tx:01] driver [NXP CBTX (SJA1110)] (irq=POLL) [ 3.661033] sja1105 spi9.0 t1-1 (uninitialized): PHY [spi9.0-base-t1:01] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.664058] sja1105 spi9.0 t1-2 (uninitialized): PHY [spi9.0-base-t1:02] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.667342] sja1105 spi9.0 t1-3 (uninitialized): PHY [spi9.0-base-t1:03] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.670592] sja1105 spi9.0 t1-4 (uninitialized): PHY [spi9.0-base-t1:04] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.673818] sja1105 spi9.0 t1-5 (uninitialized): PHY [spi9.0-base-t1:05] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.676972] sja1105 spi9.0 t1-6 (uninitialized): PHY [spi9.0-base-t1:06] driver [Generic Clause 45 PHY] (irq=POLL) [ 311.277622] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 313.313486] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off [ 326.282210] sja1105 spi9.0 t1-1: configuring for phy/internal link mode [ 330.126681] sja1105 spi9.0 t1-2: configuring for phy/internal link mode 是的,我确实使用了 PHY_ADDR 带,PHY_ADDR[4:0] 设置为 5'b010001。( 0x09 至 0x14 ) 与https://github.com/nxp-auto-linux/linux/blob/810f396375526c11989bd1a296d2f9959de9392f/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi#L141和 S32G-VNP-RDB3 原理图相同。 -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 感谢您的更新 - 目前,我认为我们最好从头开始调试,使用最小的确定性设置,因为我们现在有几个相互影响的变量(DSA 拓扑、网桥行为和 PHY 访问路径),我们需要隔离 RJ45 问题是软件(Linux/DSA/网桥/VLAN)问题还是硬件(TX 对/磁性元件)问题。 从你最初的描述中,我们可以看出一个清晰的症状模式: RJ45 RX 正常工作(可以看到来自笔记本电脑的 ARP 请求)。 RJ45 TX 不能(笔记本电脑看不到板上的任何框架)。 100BASE‑T1 仍处于关闭状态,目前我们没有足够的证据来得出结论,这是否与配置/管理路径有关,还是与物理层/训练问题有关。 这是第一步: 第 1 步 - 在不使用任何桥接器的情况下确认 RJ45 上的基本 TX ip link set eth0 up ip link set rj45 up   # 重要:移除其他设备上的 IP 以避免混乱路由 ip addr flush dev eth0 IP 地址 flush dev rj45 IP 地址 flush dev br0 2>/dev/null   # 将 IP 直接接入 RJ45 DSA 端口 ip addr add 192.168.1.1/24dev rj45   # 显示路由和地址以保持理智 ip addr show rj45 ip route show   # 产生流量 arping -I rj45 192.168.1.2 ping -I rj45 192.168.1.2 同时,在板上捕获 tcpdump -i rj45 -e -nn arp 或 icmp 笔记本电脑 tcpdump -i -e -nn arp 或 icmp 顺祝商祺! 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好, ,我还发现 eth0 链接没有显示 RUNNING,这会是问题之一吗?在进行 PING 时,RJ45 的 txbytes 会增加,但 eth0 发送的所有信息都会被丢弃。 eth0 Link encap:Ethernet HWaddr 92:56:D3:62:3D:60 UP BROADCAST MULTICAST MTU:1536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:10 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:33 rj45 Link encap:Ethernet HWaddr 92:56:D3:62:3D:60 inet6 addr: fe80::9056:d3ff:fe62:3d60/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:796 (796.0 B) # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever 2: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ee:06:ea:10:7f:d4 brd ff:ff:ff:ff:ff:ff 3: can0: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 4: can1: mtu 16 qdisc noop state DOWN group default qlen 10 link/can 5: eth0: mtu 1536 qdisc mq state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 6: eth1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:04:a3:61:cc:6f brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: rj45@eth0: mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff inet6 fe80::9056:d3ff:fe62:3d60/64 scope link proto kernel_ll valid_lft forever preferred_lft forever 9: interswitch@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 10: epc2-uplink@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 11: t1-1@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 12: t1-2@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 13: t1-3@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 14: t1-4@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 15: t1-5@eth0: mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 16: t1-6@eth0: mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff 17: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 92:56:d3:62:3d:60 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::9056:d3ff:fe62:3d60/64 scope link proto kernel_ll valid_lft forever preferred_lft forever -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 您好 1.)我尝试了同样的测试,还检查了其他一些东西来验证问题。CPU 端口 (p04) 和 RJ45 之间似乎没有编程 L2 转发路径。 以下是整个日志 ////////////////// AFTER BOOT ////////////////// # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 0 p04_n_txbyte: 0 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 0 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 0 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 0 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 # ethtool -S rj45 NIC statistics: tx_packets: 0 tx_bytes: 0 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 ////////////////// Link UP ////////////////// # ip link set eth0 up [ 69.576075] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 69.576204] MACB : HWSTAMP check running # [ 69.576257] MACB : HWSTAMP check passed found tsu_clk [ 69.577736] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. # ip link set rj45 up # [ 73.786469] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 75.841723] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off # ip addr add 192.168.1.1/24 dev rj45 # ip link set rj45 up # ip addr show rj45 8: rj45@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 scope global rj45 valid_lft forever preferred_lft forever inet6 fe80::e4e8:aeff:fe30:6b84/64 scope link proto kernel_ll valid_lft forever preferred_lft forever # ethtool -S rj45 NIC statistics: tx_packets: 10 tx_bytes: 796 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 8 n_rxbyte: 1690 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 8 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 2 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 6 n_rx_mcast: 8 # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 8 p04_n_txbyte: 1722 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 2 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 6 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 8 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 ////////////////// PING BOARD TO Laptop ////////////////// # arping -I rj45 192.168.1.2 ARPING 192.168.1.2 from 192.168.1.1 rj45 ^CSent 9 probe(s) (9 broadcast(s)) Received 0 response(s) (0 request(s), 0 broadcast(s)) # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 8 p04_n_txbyte: 1722 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 2 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 6 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 8 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 # ping -I rj45 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes ^C --- 192.168.1.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss # ethtool -S eth0 NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 8 p04_n_txbyte: 1722 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 2 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 6 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 8 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 # ethtool -S rj45 NIC statistics: tx_packets: 26 tx_bytes: 1496 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 9 n_rxbyte: 1781 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 9 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 2 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 1 n_rx_bytes_64: 6 n_rx_mcast: 9 ////////////////// PING Laptop TO Board ////////////////// # ethtool -S rj45 NIC statistics: tx_packets: 26 tx_bytes: 1496 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 15 n_rxbyte: 2165 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 9 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 2 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 1 n_rx_bytes_64: 12 n_rx_mcast: 9 2.)在 T1 端口上,我检查错了 T1 端口;T1 端口环回上也出现了链接,但 ping 却无法正常工作。 同样的日志。 ======================================== SJA1110 T1 Loopback Test Thu Jan 1 00:03:16 UTC 1970 ======================================== === Bring Interfaces Up === === Configure IP Addresses === 15: t1-5@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 scope global t1-5 valid_lft forever preferred_lft forever 16: t1-6@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff inet 192.168.10.2/24 scope global t1-6 valid_lft forever preferred_lft forever === Link Status === Settings for t1-5: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 5 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Link detected: yes Settings for t1-6: Supported ports: [ ] Supported link modes: 100baseT1/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 100baseT1/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 6 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Link detected: yes === VLAN Configuration === port vlan-id === FDB Before Traffic === 33:33:00:00:00:01 dev bond0 self permanent 33:33:00:00:00:01 dev eth0 self permanent 01:00:5e:00:00:01 dev eth0 self permanent 33:33:00:00:00:01 dev eth1 self permanent === Interface Counters BEFORE === 5: eth0: mtu 1536 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 16 0 0 15: t1-5@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 696 8 0 0 0 0 16: t1-6@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 696 8 0 0 0 0 === Ethtool Stats BEFORE === NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 0 p04_n_txbyte: 0 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 0 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 0 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 0 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 NIC statistics: tx_packets: 8 tx_bytes: 696 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 NIC statistics: tx_packets: 8 tx_bytes: 696 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 === ARP Test === ARPING 192.168.10.2 from 192.168.10.1 t1-5 Sent 10 probe(s) (0 broadcast(s)) Received 0 response(s) (0 request(s), 0 broadcast(s)) === Neighbor Table === === Interface Counters AFTER === 5: eth0: mtu 1536 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 26 0 0 15: t1-5@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 1116 18 0 0 0 0 16: t1-6@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e6:e8:ae:30:6b:84 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 696 8 0 0 0 0 === Ethtool Stats AFTER === NIC statistics: tx_octets: 0 tx_frames: 0 tx_broadcast_frames: 0 tx_multicast_frames: 0 tx_pause_frames: 0 tx_64_byte_frames: 0 tx_65_127_byte_frames: 0 tx_128_255_byte_frames: 0 tx_256_511_byte_frames: 0 tx_512_1023_byte_frames: 0 tx_1024_1518_byte_frames: 0 tx_greater_than_1518_byte_frames: 0 tx_underrun: 0 tx_single_collision_frames: 0 tx_multiple_collision_frames: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_deferred_frames: 0 tx_carrier_sense_errors: 0 rx_octets: 0 rx_frames: 0 rx_broadcast_frames: 0 rx_multicast_frames: 0 rx_pause_frames: 0 rx_64_byte_frames: 0 rx_65_127_byte_frames: 0 rx_128_255_byte_frames: 0 rx_256_511_byte_frames: 0 rx_512_1023_byte_frames: 0 rx_1024_1518_byte_frames: 0 rx_greater_than_1518_byte_frames: 0 rx_undersized_frames: 0 rx_oversize_frames: 0 rx_jabbers: 0 rx_frame_check_sequence_errors: 0 rx_length_field_frame_errors: 0 rx_symbol_errors: 0 rx_alignment_errors: 0 rx_resource_errors: 0 rx_overruns: 0 rx_ip_header_checksum_errors: 0 rx_tcp_checksum_errors: 0 rx_udp_checksum_errors: 0 q0_rx_packets: 0 q0_rx_bytes: 0 q0_rx_dropped: 0 q0_tx_packets: 0 q0_tx_bytes: 0 q0_tx_dropped: 0 q1_rx_packets: 0 q1_rx_bytes: 0 q1_rx_dropped: 0 q1_tx_packets: 0 q1_tx_bytes: 0 q1_tx_dropped: 0 q2_rx_packets: 0 q2_rx_bytes: 0 q2_rx_dropped: 0 q2_tx_packets: 0 q2_tx_bytes: 0 q2_tx_dropped: 0 q3_rx_packets: 0 q3_rx_bytes: 0 q3_rx_dropped: 0 q3_tx_packets: 0 q3_tx_bytes: 0 q3_tx_dropped: 0 p04_: 0 p04_n_runt: 0 p04_n_soferr: 0 p04_n_alignerr: 0 p04_n_miierr: 0 p04_typeerr: 0 p04_sizeerr: 0 p04_tctimeout: 0 p04_priorerr: 0 p04_nomaster: 0 p04_memov: 0 p04_memerr: 0 p04_invtyp: 0 p04_intcyov: 0 p04_domerr: 0 p04_pcfbagdrop: 0 p04_spcprior: 0 p04_ageprior: 0 p04_portdrop: 0 p04_lendrop: 0 p04_bagdrop: 0 p04_policeerr: 0 p04_drpnona664err: 0 p04_spcerr: 0 p04_agedrp: 0 p04_n_n664err: 0 p04_n_vlanerr: 0 p04_n_unreleased: 0 p04_n_sizeerr: 0 p04_n_crcerr: 0 p04_n_vlnotfound: 0 p04_n_ctpolerr: 0 p04_n_polerr: 0 p04_n_rxfrm: 0 p04_n_rxbyte: 0 p04_n_txfrm: 0 p04_n_txbyte: 0 p04_n_qfull: 0 p04_n_part_drop: 0 p04_n_egr_disabled: 0 p04_n_not_reach: 0 p04_n_drops_nolearn: 0 p04_n_drops_noroute: 0 p04_n_drops_ill_dtag: 0 p04_n_drops_dtag: 0 p04_n_drops_sotag: 0 p04_n_drops_sitag: 0 p04_n_drops_utag: 0 p04_n_tx_bytes_1024_2047: 0 p04_n_tx_bytes_512_1023: 0 p04_n_tx_bytes_256_511: 0 p04_n_tx_bytes_128_255: 0 p04_n_tx_bytes_65_127: 0 p04_n_tx_bytes_64: 0 p04_n_tx_mcast: 0 p04_n_tx_bcast: 0 p04_n_rx_bytes_1024_2047: 0 p04_n_rx_bytes_512_1023: 0 p04_n_rx_bytes_256_511: 0 p04_n_rx_bytes_128_255: 0 p04_n_rx_bytes_65_127: 0 p04_n_rx_bytes_64: 0 p04_n_rx_mcast: 0 NIC statistics: tx_packets: 18 tx_bytes: 1116 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 NIC statistics: tx_packets: 8 tx_bytes: 696 rx_packets: 0 rx_bytes: 0 : 0 n_runt: 0 n_soferr: 0 n_alignerr: 0 n_miierr: 0 typeerr: 0 sizeerr: 0 tctimeout: 0 priorerr: 0 nomaster: 0 memov: 0 memerr: 0 invtyp: 0 intcyov: 0 domerr: 0 pcfbagdrop: 0 spcprior: 0 ageprior: 0 portdrop: 0 lendrop: 0 bagdrop: 0 policeerr: 0 drpnona664err: 0 spcerr: 0 agedrp: 0 n_n664err: 0 n_vlanerr: 0 n_unreleased: 0 n_sizeerr: 0 n_crcerr: 0 n_vlnotfound: 0 n_ctpolerr: 0 n_polerr: 0 n_rxfrm: 0 n_rxbyte: 0 n_txfrm: 0 n_txbyte: 0 n_qfull: 0 n_part_drop: 0 n_egr_disabled: 0 n_not_reach: 0 n_drops_nolearn: 0 n_drops_noroute: 0 n_drops_ill_dtag: 0 n_drops_dtag: 0 n_drops_sotag: 0 n_drops_sitag: 0 n_drops_utag: 0 n_tx_bytes_1024_2047: 0 n_tx_bytes_512_1023: 0 n_tx_bytes_256_511: 0 n_tx_bytes_128_255: 0 n_tx_bytes_65_127: 0 n_tx_bytes_64: 0 n_tx_mcast: 0 n_tx_bcast: 0 n_rx_bytes_1024_2047: 0 n_rx_bytes_512_1023: 0 n_rx_bytes_256_511: 0 n_rx_bytes_128_255: 0 n_rx_bytes_65_127: 0 n_rx_bytes_64: 0 n_rx_mcast: 0 === FDB After Traffic === 33:33:00:00:00:01 dev bond0 self permanent 33:33:00:00:00:01 dev eth0 self permanent 01:00:5e:00:00:01 dev eth0 self permanent 33:33:00:00:00:01 dev eth1 self permanent === Dmesg Link Events === [ 3.602806] sja1105 spi9.0: Link is Up - 1Gbps/Full - flow control off [ 3.678860] sja1105 spi9.0 t1-5 (uninitialized): PHY [spi9.0-base-t1:05] driver [Generic Clause 45 PHY] (irq=POLL) [ 3.682052] sja1105 spi9.0 t1-6 (uninitialized): PHY [spi9.0-base-t1:06] driver [Generic Clause 45 PHY] (irq=POLL) [ 196.222060] sja1105 spi9.0 t1-5: configuring for phy/internal link mode [ 196.224821] sja1105 spi9.0 t1-5: Link is Up - 100Mbps/Full - flow control off [ 196.229425] sja1105 spi9.0 t1-6: configuring for phy/internal link mode [ 196.231212] sja1105 spi9.0 t1-6: Link is Up - 100Mbps/Full - flow control off Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好 @PavelL 即使在网桥创建之后,我也看到没有字节离开交换机。 # ip link set eth0 up [ 78.263728] macb 20110000.ethernet eth0: configuring for fixed/sgmii link mode [ 78.263859] MACB : HWSTAMP check running # [ 78.263911] MACB : HWSTAMP check passed found tsu_clk [ 78.265094] macb 20110000.ethernet: gem-ptp-timer ptp clock registered. ip addr flush dev rj45 # ip link add name br0 type bridge # ip link set br0 type bridge vlan_filtering 0 # ip link set rj45 master br0 [ 119.331341] br0: port 1(rj45) entered blocking state [ 119.331506] br0: port 1(rj45) entered disabled state [ 119.331588] sja1105 spi9.0 rj45: entered allmulticast mode # [ 119.331615] macb 20110000.ethernet eth0: entered allmulticast mode [ 119.339852] sja1105 spi9.0 rj45: entered promiscuous mode ip addr add 192.168.1.1/24 dev br0 # ip link set rj45 up # [ 130.485390] sja1105 spi9.0 rj45: configuring for phy/internal link mode [ 132.518207] sja1105 spi9.0 rj45: Link is Up - 100Mbps/Full - flow control off ip link set br0 up # [ 137.057392] br0: port 1(rj45) entered blocking state [ 137.057430] br0: port 1(rj45) entered forwarding state # ethtool -S rj45 | grep -E "n_txfrm|n_rxfrm|n_not_reach" n_rxfrm: 7 n_txfrm: 0 n_not_reach: 7 # ping -c 5 -I br0 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes --- 192.168.1.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss # ethtool -S rj45 | grep -E "n_txfrm|n_rxfrm|n_not_reach" n_rxfrm: 14 n_txfrm: 0 n_not_reach: 14 这是配置问题吗? -- 安库尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@Ankur_pixl、 感谢您提供的详细日志。请随时纠正我的解释。 您的最新结果非常有用,因为它们表明这很可能不再是一个单纯的桥梁问题。 对于 RJ45 直接 L3 测试(IP 直接分配到 rj45,无网桥),Linux netdev TX 计数器会增加,但 RJ45 端口的硬件交换机出口计数器仍为 0(`n_txfrm = 0`,`n_txbyte = 0`)。同时,RJ45 上的入口计数器也会增加,这表明前端 PHY/链路正在正确接收帧。 T1 回环结果也指向同一方向:两个 T1 端口都成功链接,因此 PHY 培训本身似乎有效,但流量仍无法通过。 这两种情况的共同点是 CPU/主控路径: - `eth0` 保持 `NO-CARRIER` - `eth0` 保持 `state DOWN` - MACB TX/RX 硬件计数器保持为 0 - `eth0` 的 TX 丢弃数据包增加 由此看来,主要问题是 SoC MAC (`eth0`)和 SJA1110 CPU 端口 (p04) 之间的 CPU 导管路径,而不是前 RJ45 或 T1 PHY 端口本身。 换句话说,交换机侧端口可以启动,但面向主机的 SGMII/CPU 端口数据路径似乎无法运行。 在现阶段,我建议将重点放在 SoC MAC / PCS / SGMII 的 "eth0 "配置以及相应的 CPU 端口配置上,而不是进一步进行桥接实验。 请分享: 1. ethtool eth0 2. ip-d link show eth0 3. 连接到交换机 CPU 端口的 SoC MAC/PCS/SGMII 端的完整设备树片段 4. SoC 端任何可用的 PCS/SGMII 链接状态信息 eth0` 从未达到 RUNNING / carrier-up(运行/载波启动)是一个强有力的指标,很可能与流量故障有关。 我再次查看了你的 DT 片段,设备树的 DSA/SJA1110 部分在逻辑上看起来是一致的: -MAC0 配置为 “sgmii”,具有固定的 1 Gbps 全双工链路-SJA1110 CPU 端口也被配置为 “sgmii”,带有固定的 1 Gbps 全双工链路 ——内部 PHY 端口映射看起来也正确 因此,目前我看不出这个片段本身存在明显的 DSA DT 错误。 然而,仅凭这个 DT 片段并不能证明 SoC 端 SGMII/PCS/SerDes 通路确实在运行。根据您的计数器,交换机 CPU 端口在交换机一侧似乎处于活动状态,但 `eth0` 仍处于 `NO-CARRIER` / DOWN 状态,没有真正的 MAC RX/TX 流量。 这表明面向 SoC 的 SGMII/PCS/SerDes 路径(或其低级初始化)存在问题,而不是前面的 RJ45 或 T1 端口。 能否请您分享完整的 MAC0 / PCS / SerDes 相关配置,以及初始化 SGMII 通道的任何引导加载程序/底层配置? 顺祝商祺! 帕维尔 Re: SJA1110A DSA bring UP : 100BASE-TX TX failure and T1 link training issues 你好@PavelL 是的,在仔细查看原理图后,我发现从 SoC 到交换机的 SGMII TX P/N 线路被调换了。此外,相同的 SGMII 线路连接到了另一个端点,导致以太网链路无法连接。 我们目前正在修复这些问题,并将向您提供最新结果。 -- 安库尔
記事全体を表示
使用 SE052F 的 RNG OpenSSL 提供程序 我们需要使用 SE052F 作为符合 FIPS 标准的随机数生成源。我们要求 OpenSSL 使用 SE052F,进而要求所有使用 openssl 库的应用程序使用 SE052F 作为 RNG。 我知道我们必须使用 NXP MW accessManager 和 OpenSSL Provider。 我正在使用SE-PLUG-TRUST-MW_04.07.01 我已按照以下说明进行操作: AN14028.pdf SE-PLUG-TRUST-MW_04.07.01/simw-top/doc/hostlib/hostLib/accessManager/doc/accessManager.html and the README info here (but not using this 仓库): https://github.com/NXPPlugNTrust/se05x-openssl-provider AccessManager 使用以下 cmake 选项构建: NXP_SE_MW_CONF_OPTS += -DWithSharedLIB=OFF -DPTMW_Host=Raspbian -DPTMW_SMCOM=T1oI2C -DPTMW_Applet=SE05X_C \ -DPTMW_FIPS=None -DPTMW_SE05X_Ver=07_02 -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_SCP=SCP03_SSS -DSE05X_EN_PIN=582 -DSE_RESET_LOGIC=0 \ -DPAHO_BUILD_SHARED=FALSE -DPAHO_BUILD_STATIC=TRUE 使用以下 cmake 选项构建的 OpenSSL 提供商: NXP_SE_MW2_CONF_OPTS += -DWithSharedLIB=ON -DPTMW_HostCrypto=OPENSSL -DPTMW_Host=Raspbian -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_SE05X_Auth=None openssl.cnf 修改如下: [provider_sect] nxp_prov = nxp_sect default = default_sect [nxp_sect] identity = nxp_prov module = /usr/lib/libsssProvider.so activate = 1 [default_sect] activate = 1 访问管理器启动: Starting accessManager (Rev.1.1). Protect Link between accessManager and SE: YES. accessManager JRCPv1 (T1oI2C SE side) ****************************************************************************** Server: waiting for connections on port 8040. Server: only localhost based processes can connect. 从命令行使用 openssl 的 RNG 似乎运行正常: # openssl rand -hex 64 sssprov-dbg: Enter - OSSL_provider_init App :INFO :Using PortName='127.0.0.1:8040' (gszSocketPortDefault) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. New client connection from 127.0.0.1. Client ID: 5 Command 0x00 from client 5 DUMMY_ATR=0x01.A0.00.00.03.96.04.03.E8.00.FE.02.0B.03.E8.00.01.00.00.00.00.64.13.88.0A.00.65.53.45.30.35.31.00.00.00. Replacing *_ATR by default (pre-cooked) ATR. ATR=0x3B.FB.18.00.00.81.31.FE.45.50.4C.41.43.45.48.4F.4C.44.45.52.AB. Command 0x01 from client 5 SM_EstablishPlatformSCP03Am (Entry) App :WARN :Using SCP03 keys from:'/tmp/SE05X/plain_scp.txt' (FILE=/tmp/SE05X/plain_scp.txt) SE051 connected. SM_EstablishPlatformSCP03Am (Exit); Status = 0x9000 sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_enable_locking sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_get_ctx_params sssprov-dbg: Enter - sss_rand_generate sssprov-flw: Get random data from SE05x Command 0x01 from client 5 SM_SendAPDUAm: smStatus = 0x9000 5f0f4d63e4ec771b8cfd46dd50c497b7e4e56e203ad5bc6eca9f8c28d23f39aa2d4a807915e3c60cf2e6a833794cb1208554f3e635811354eadd7b2c911c60da sssprov-dbg: Enter - sss_rand_freectx sssprov-dbg: Enter - sss_rand_freectx sssprov-dbg: Enter - sss_teardown Received 0 byte from client 5 (Message Header Phase) . 但是,启动 ssh 守护进程失败了: # /usr/sbin/sshd & sssprov-dbg: Enter - OSSL_provider_init App :INFO :Using PortName='127.0.0.1:8040' (gszSocketPortDefault) App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. New client connection from 127.0.0.1. Client ID: 5 Command 0x00 from client 5 ATR=0x3B.FB.18.00.00.81.31.FE.45.50.4C.41.43.45.48.4F.4C.44.45.52.AB. Command 0x01 from client 5 Pre-cooked response (rspAppletSelect) sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! sssprov-dbg: Enter - sss_rand_newctx sssprov-dbg: Enter - sss_rand_instantiate sssprov-dbg: Enter - sss_rand_enable_locking sssprov-dbg: Enter - sss_rand_get_ctx_params PRNG is not seeded Received 0 byte from client 5 (Message Header Phase) . [2]+ Done(255) /usr/sbin/sshd 如有任何帮助,我将不胜感激、 Sam Re: OpenSSL Provider with SE052F for RNG 你好@sam123、 我们的提供商目前尚未测试 Openssh 支持。 这需要进一步分析,并可能需要修改。 已为 RnD 创建了内部票据,他们将进行分析。 如果我从那里得到更多信息,我会告诉你的。 感谢您的耐心等待! 祝您愉快, Kan ------------------------------------------------------------------------------- 注: - 如果本帖回答了您的问题,请点击"标记正确" 按钮。谢谢! - 我们会在最后一次发帖后的 7 周内跟踪主题,之后的回复将被忽略 如果您以后有相关问题,请另开新主题,并参考已关闭的主题。 -------------------------------------------------------------------------------
記事全体を表示
错误的 MDC 频率 RW612 frdm_rw612 大家好 在开发过程中,我遇到了以太网连接稳定性问题。在同时使用rw612定制主板和frdm_rw612进行了一些调查后,发现MDC引脚上的频率是错误的。不是 2.5 兆赫,而是 13 兆赫。由于以太网模块 ksz8081 允许高达 10 MHz 的 MDC 频率,因此以太网能在 frdm_rw612 上稳定工作只是运气好而已(您可以从 Zephyr 闪存任何以太网示例,查看 frdm_rw612 上 MDC 引脚的频率是否为 13 MHz) 深入研究后发现,问题的根源似乎在于以太网 MSCR 寄存器,该寄存器在计算 MII_SPEED 时使用固定的 50MHz 时钟值。我在 Zephyr 的 mcux/mcux-SDK/devices/rw612/drivers/fsl_clock 的 clock_gettdrmcienetclk Freq(void)函数下找到了它。 c。 当我使用 M33 处理器频率(260 MHz)计算这个寄存器值时,我看到了正确的 MDC 频率 - 2.5MHz。 根据 RW612 数据表,代码中的频率(50 MHz)似乎是正确的,但实际上它使用 260 MHz 的时钟作为计算参考。 最初,我更改了 CLOCK_GetTddrMciEnetClkFreq 的返回值改为 260 MHz。的返回值改为 260 MHz,但我不确定这是否会影响代码的其他部分,不过现在已经可以正常工作了。 能否请您确认该问题是否存在,并帮助我在哪里解决? RW612 Re: Wrong MDC frequency RW612 frdm_rw612 赞一个@Maciej_Jj 感谢你们发现并解决了这个问题! 我的项目也是基于 zephyr 的,但就是因为这个问题卡住了。 Re: Wrong MDC frequency RW612 frdm_rw612 您好,Maciej, 我正在查看您的所有输入,是的,您找到了需要修复的相关问题。为了快速解决问题,您可以在函数 CLOCK_GetTddrMciEnetClkFreq 中将 CLOCK_MHZ 的值改为 260MHz。您可以继续工作,我们将在 GitHub 代码库中进行更新。 致以最崇高的敬意, Pavel Krenek Re: Wrong MDC frequency RW612 frdm_rw612 你好,里卡多、 是否有任何更新? Re: Wrong MDC frequency RW612 frdm_rw612 在 MCUxpresso 样本中,似乎使用 260 MHz 频率来计算 MSCR 寄存器的值: Re: Wrong MDC frequency RW612 frdm_rw612 您好, 没问题,我已经使用 MCUXpresso IDE 24.9.25 更新了 frdmrw612_enet_txrx_transfer 样品,在这里一切正常,MDC 引脚的测量频率为 2.5 MHz。 Re: Wrong MDC frequency RW612 frdm_rw612 你好 我知道您使用的是 Zephyr,但能否请您帮助我们检查一下在使用 MCUXpresso SDK 时是否也会出现这个问题? 在此期间,我还将查看 Zephyr 的例子。 此致, 里卡多 Re: Wrong MDC frequency RW612 frdm_rw612 在这里,我将测量 MDC 频率的 CLOCK_GetTddrMciEnetClkFreq 更 改为 260 MHz: Re: Wrong MDC frequency RW612 frdm_rw612 你好,里卡多、 我们的产品正在开发 Zephyr 3.7,但为了确保这个问题可以重现,我设置了 Zephyr 4.1.0.rc3,它使用 ZephyrSDK 0.17.0,在 west.yml 中我看到它指向 HAL 恩智浦修订版。9dc7449014a7380355612453b31be479cb3a6833(https://github.com/zephyrproject-rtos/hal_nxp/commits/9dc7449014a7380355612453b31be479cb3a6833). 我使用以下命令从 Zephyr 示例中构建 dhcpv4 示例: west build-b frdm_rw612 samples/net/dhcpv4_client/-p 闪烁后,我在控制台看到该示例正确启动。我在 GPIO56 上测量了频率(正好在 frdm_rw612 主板上的 R31 上)。请参见 frdm_rw612 原理图中的图片:   测量频率约为 13 兆赫。根据 ksz8081 数据手册,它的频率不得超过 10MHz,最佳条件是该频率为 2.5MHz: 查看 MSCR 寄存器,其值似乎正确,但实际上必须使用 260 MHz 频率重新计算,而不是 50 MHz。因此,MSCR MII_SPEED 为 13MHz 而不是 2.5MHz,MSCR HOLDTIME 设置为 0,导致连接问题。 我在 enet devicetree 中做了一些变通,但不能这样。使用以下方法会导致 HOLDTIME 值出错,并且仍然存在一些通信问题。 我没有尝试 mcuexpresso 的 eth 示例,因为我们使用 Zephyr 进行开发 Re: Wrong MDC frequency RW612 frdm_rw612 你好 希望你一切顺利。能否详细介绍一下您的设置? 您使用的是哪个版本的 SDK?您尝试使用 SDK 中的以太网示例了吗? 您是如何使用 FRDM 进行测量的? 顺祝商祺! 里卡多
記事全体を表示
S32K3使用技巧汇总_skill_experience Hi,  一些经验汇总如附件。包含主题如下: S32K3 Cortex-M7的DSP能力(Liek Li).docx S32K3 GCC版本与RTD版本的对应支持关系_Box Li 202312.docx S32K3 HSE_B资源汇总及获取流程(Liek Li).docx S32K3 MaxQFP的生产检测建议(Mike Cao).txt S32K3 NXP代理商关于S32K3的参考设计汇总(Seth Wang).docx S32K3 NXP关于S32K3的参考设计和资料汇总(Seth Wang).docx S32DS的版本管理及对应的RTD下载及安装_Box Li 202312.docx S32K3 JTAG加密及调试_JayceYang.pptx S32K3 LifeCycle的使用建议_JayceYang.docx S32K3 PN与HSE_B FW版本映射关系_JayceYang.pptx S32K3 sBAF与HSE_B FW的版本关系_JayceYang.pptx S32K3 TCM使用建议_(Box Li).docx S32K3 XRDC的使用场景及技巧(Liek Li) .docx S32K3+SBC的使用建议(Alvin Liu).pdf S32K3_LinkerFile_JayceYang.docx S32K3功能安全文档的获取及开发流程_WeoWang.docx S32K3在BMS应用的软硬件资源汇总_WeoWang.docx S32K3基于外设的培训资料汇总及样例(Seth Wang).docx S32K3的ETH应用(Liek Li).docx S32K3的Hardfault问题分析步骤(Alvin Liu).pdf S32K3的HSE_B FW安装 (Alvin Liu).pdf S32K3的RTD软件架构及使用建议(Seth Wang).docx S32K3的SAF(SPD)获取及集成建议(Ives CHENG).pdf S32K3的sBAF更新办法(Alvin Liu).pdf S32K3的SCST获取使用建议(Ives CHENG).pdf S32K3的“EB+命令行开发”环境搭建及实验(Alvin Liu).pdf S32K3的中断机制_Box Li 202312.docx S32K3的使用技巧_AHB总线上QSPI的使用建议_(Oliver TIAN).txt S32K3的使用技巧_ISELED应用上的PN选取及开发建议_(Oliver TIAN).txt S32K3的使用技巧_S32DS工程和iAR工程的相互迁移_(Jacky TAN).txt S32K3的使用技巧_S32K3 OTA的实现_(Jacky TAN).txt S32K3的使用技巧_S32K3的bootloader_(Jacky TAN).txt S32K3的使用技巧_S32K3的FEE ECC处理机制_(Jacky TAN).txt S32K3的使用技巧_S32K3的低功耗管理及唤醒样例汇总_(Jacky TAN).txt S32K3的使用技巧_S32K3的启动性能分析_(Jacky TAN).txt S32K3的功能安全开发流程及资料_Box Li 202312.docx S32K3的启动过程讲解_Box Li 202312.docx S32K3的多核调试建议及示例_(Ives CHENG).docx S32K3的时钟配置建议(Seth Wang).docx S32K3的电机控制基础及资料_WeoWang.docx S32K3硬件设计检查建议_WeoWang.docx S32K3调试中ETM的使用展示(Ives CHENG).docx S32K3问题发生后的信息搜集(Charles Zhao).docx S32K3 Security名词解释(Charles Zhao).docx S32K3 阅读勘误手册注意事项(Charles Zhao).docx 希望能够有所帮助  Oliver Re: S32K3使用技巧汇总_skill_experience 太干了 感谢楼主 Re: S32K3使用技巧汇总_skill_experience 谢谢! 能否提供英文版? 回复: S32K3使用技巧汇总_skill_experience 下载了,感谢感谢 Re: S32K3使用技巧汇总_skill_experience 原文的最后有下载压缩包 Re: S32K3使用技巧汇总_skill_experience 有示例代码吗 Re: S32K3使用技巧汇总_skill_experience 在哪下载,你更新在哪啊 Re: S32K3使用技巧汇总_skill_experience 已更新下载包链接 回复: S32K3使用技巧汇总_skill_experience 已更新下载包链接 回复: S32K3使用技巧汇总_skill_experience 请问怎么能获取下载连接 Re: S32K3使用技巧汇总_skill_experience 怎么获取下载链接 Re: S32K3使用技巧汇总_skill_experience Hi Oliver,      怎么获取到下载连接? Re: S32K3使用技巧汇总_skill_experience 请欣赏这些纸张! 奥利弗
記事全体を表示
T1040 板上的 PCI 内存分配(BAR 寄存器) 你好, 我的问题很简单,PCI 没有在 t10420 主板上分配内存。 以下是 “dmesg” 消息和 u-boot 消息。 PCI:探测 PCI 硬件 fsl-pci ffe250000.pcie:PCI 主机桥接到总线 0001:00 pci_bus 0001:00:根总线资源 [io 0xf1050000-0xf105ffff](总线地址 [0x0000-0xffff])pci_bus 0001:00:根总线资源 [mem 0xc100000000-0xc1fffff](总线地址 [0xe0000000-0xefffff])pci_bus 0001:00:根总线资源 [mem 0xc1000000-0x1fffff](总线地址 [0xe0000000-0xefffff]) pci_bus 0001:00:根总线资源 [mem 0xcbus 0001:00:根总线资源 [bus 00-ff] pci_bus 0001:00:busn_res:[bus 00-ff] 结束已更新为 ff pci 0001:00:00.0: [1957:0820] type 01 class 0x060400 pci 0001:00:00.0:reg 0x10: [mem 0xff000000-0xffffffffff] pci 0001:00:00.0:支持 D1 D2 pci 0001:00:00.0:从 D0 D1 D2 D3hot D3cold 支持 PME# fsl-pci ffe250000.pcie:从 iommu 组 19 移除 pci 0001:00:00.0:添加到 iommu 组 21 pci 0001:01:00.0:[1002:6987] type 00 class 0x030000 pci 0001:01:00.0:reg 0x10: [mem 0xc10000000-0xc1fffffff 64bit pref] pci 0001:01:00.0:reg 0x18: [mem 0x1000ffe00000-0x1000ffffffff 64bit pref] pci 0001:01:00.0:reg 0x20: [io 0xf1051100-0xf10511ff] pci 0001:01:00.0:reg 0x24: [mem 0xfffc0000-0xffffffffff] pci 0001:01:00.0:reg 0x30: [mem 0xfffe0000-0xffffffff pref] pci 0001:01:00.0:启用扩展标记 pci 0001:01:00.0:支持 D1 D2 pci 0001:01:00.0:D1 D2 D3hot D3cold pci 0001:01:00.0 支持 PME#:可用 PCIe 带宽为 4.000 Gb/s,在 0001:00:00.0 时受 5.0 GT/s PCIe x1 链接限制(使用 8.0 GT/s PCIe x8 链接可达到 63.008 Gb/s) pci 0001:01:00.0:添加到 iommu 组 21 pci 0001:01:00.1:[1002:aae0] type 00 class 0x040300 pci 0001:01:00.1:reg 0x10: [mem 0x1200ffffc000-0x1200ffffff 64bit] pci 0001:01:00.1:启用扩展标记 pci 0001:01:00.1:支持 D1 D2 pci 0001:01:00.1:添加到 iommu 组 21 pci 0001:00:00.0:PCI 桥接到 [总线 01-ff] pci 0001:00:00.0:bridge window [io 0xf1051000-0xf1051fff] pci 0001:00:00.0:桥接窗口 [mem 0xc100000000-0xc1fffff] pci_bus 0001:01:busn_res:[总线 01-ff] 末端更新为 01 p ci_bus 0001:00:busn_res:[总线 00-ff] 端已更新为 01 PCI:无法分配设备 0001:00:0 的资源区域 0,将重新映射 PCI:无法分配设备 0001:00:0 的资源区域 2 01:00.0,将重新映射 PCI:无法分配设备 0001:01:00.0 的资源区域 5,将重新映射 PCI:无法分配设备 0001:01:00.0 的资源区域 6,将重新映射 PCI:无法分配设备 0001:01:00.1 的资源区域 0,将重新映射 pci 0001:00:00.0:BAR 0: no space for [mem size 0x01000000] pci 0001:00:00.0:BAR 0:分配失败 [内存大小 0x01000000] pci 0001:00:00.0:BAR 9:无空间 [内存大小 0x00200000 64 位前缀] pci 0001:00:00.0:BAR 9:分配失败 [内存大小 0x00200000 64 位前缀] pci 0001:01:00.0:BAR 2: no space for [mem size 0x00200000 64bit pref] pci 0001:01:00.0:BAR 2:分配失败 [内存大小 0x00200000 64 位前缀] pci 0001:01:00.0:BAR 5: no space for [mem size 0x00040000] pci 0001:01:00.0:BAR 5:分配失败 [内存大小 0x00040000] pci 0001:01:00.0:BAR 6: no space for [mem size 0x00020000 pref] pci 0001:01:00.0:BAR 6:分配失败 [内存大小 0x00020000 pref] pci 0001:01:00.1:BAR 0: no space for [mem size 0x00004000 64bit] pci 0001:01:00.1:BAR 0:分配失败 [内存大小 0x00004000 64 位] pci 0001:00:00.0:PCI 桥接到 [总线 01] pci 0001:00:00.0:bridge window [io 0xf1050000-0xf105ffff] pci 0001:00:00.0:桥接窗口 [mem 0xc1000000-0xc1fffff] pci_bus 0001:00:部分 PCI 设备资源未分配,尝试使用 pci=realloc pci_bus 0001:00 启动:资源 4 [io 0xf105000000-0xf105ffff] pci_bus 0001:00:资源 5 [mem 0xc100000000-0xc1fffff] pci_bus 0001:00:资源 5 [mem 0xc100000000-0xc1fffff] pci_b us 0001:00:资源 5 [mem 0xc100000000-0xc1fffff] pci_bus fff] pci_bus 0001:01:资源 0 [io 0xf1050000-0xf105fff] pci_bus 0001:01:资源 1 [mem 0xc1000000-0xc1fffff] HugeTLB 注册了 4.00 MiB 页面大小,预先分配 0 页 HugeTLB 注册了 64.0 MiB 页面大小大小,预计 已分配 0 页 HugeTLB 注册了 256 MiB 页面大小,预先分配 0 页 HugeTLB 注册了 1.00 GiB 页面大小,预先分配 0 页 飞思卡尔 Elo 系列 DMA 驱动程序以下是内核 dts pci1:pcie@ffe250000 { reg =<0xf 0xfe250000 0 0x10000>; ranges =<0x02000000 0 0xe0000000 0xc 0x10000000 0 0x10000000 0x01000000 0 0xf 0xf8010000 0 0x00010000>; pcie@0 { ranges =<0x02000000 0 0xe0000000 0x02000000 0 0xe0000000 0 0x10000000 0x01000000 0 0x00000000 0x01000000 0 0x00000000 0 0x00010000>; }; }; Re: PCI memory allocation (BAR Registers) on T1040 Board GPU 的 BAR 2 请求 0x1000ffe00000 - 这是一个 64 位可预取 BAR ,试图使用 ~163 Terabytes 的地址 。这完全超出了 32 位 PCI 窗口。 T1040 是 32 位 PowerPC e5500 内核 ,通过 MMU 拥有 36 位物理地址空间 。 0x1000ffe00000 而 T1040 硬件不可能提供 48 位地址空间。 您的地址 0x1000ffe00000 在 40 多位的范围内,完全超出了 T1040 的寻址空间。 Re: PCI memory allocation (BAR Registers) on T1040 Board 是的,它是 E9171 AMDGPU Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955 你连接到 T1040 的端点设备是什么?这是 GPU 吗? Re: PCI memory allocation (BAR Registers) on T1040 Board 你好 谢谢你的回复 没什么变化 PCI 主机桥 /pcie @ffe250000 范围: MEM 0x0000000c100000000... 0x0000000c2fffff-> 0x00000000e000000e0000000 IO 0x00000000... 0x0000000ff105fff-> 0x00000000000000 /pcie @ffe250000:PCICSRBAR @ 0xdf000000 setup_pcie ci_atmu:动态随机存取存储器(DRAM) 80000000 平台的终结 ff6000000 .qman-portal: 添加到 iommu 组 0 platform ff6004000.qman-portal:添加到 iommu 组 1 platform ff6008000.qman-portal:添加到 iommu 组 2 平台 ff600c000.qman-portal:添加到 iommu 组 3 platform ff6010000.qman-portal:添加到 iommu 组 4 platform ff6014000.qman-portal:添加到 iommu 组 5 platform ff6018000.qman-portal:添加到 iommu 组 6 平台 ff601c000.qman-portal:添加到 iommu 组 7 platform ff6020000.qman-portal:添加到 iommu 组 8 平台 ff6024000.qman-portal:添加到 iommu 组 9 平台 ffe100300.dma:添加到 iommu 组 10 平台 ffe101300.dma:添加到 iommu 组 11 平台 ffe114000.sdhc:添加到 iommu 组 12 平台 ffe210000.usb:添加到 iommu 组 13 平台 ffe211000.usb:添加到 iommu 组 14 平台 ffe220000.sata:添加到 iommu 组 15 平台 ffe221000.sata:添加到 iommu 组 16 platform ffe318000.qman:添加到 iommu 组 17 平台 ffe31a000.bman:添加到 iommu 组 18 fsl-pci ffe250000.pcie:添加到 iommu 组 19 平台 ffe140000.qe:添加到 iommu 组 20 software IO TLB: tearing down default memory pool PCI: Probing PCI hardware fsl-pci ffe250000.pcie:PCI 主机桥接到总线 0001:00 pci_bus 0001:00:根总线资源 [io 0xf1050000-0xf105ffff](总线地址 [0x0000-0xffff])pci_bus 0001:00:根总线资源 [mem 0xc100000000-0xc2ffffff](总线地址 [0xe0000000-0xffffff])pci_bus 0001:00:根总线资源 [mem 0xc1000000-0xc2ffffff](总线地址 [0xe0000000-0xffffff]) pci_bus 0001:00:根总线资源 [mem bus 0001:00:根总线资源 [bus 00-ff] pci_bus 0001:00:busn_res:[bus 00-ff] 结束已更新为 ff pci 0001:00:00.0: [1957:0820] type 01 class 0x060400 pci 0001:00:00.0:reg 0x10: [mem 0xdf000000-0xdfffffff] pci 0001:00:00.0:支持 D1 D2 pci 0001:00:00.0:从 D0 D1 D2 D3hot D3cold 支持 PME# fsl-pci ffe250000.pcie:从 iommu 组 19 移除 pci 0001:00:00.0:添加到 iommu 组 21 pci 0001:01:00.0:[1002:6987] type 00 class 0x030000 pci 0001:01:00.0:reg 0x10: [mem 0xc10000000-0xc1fffffff 64bit pref] pci 0001:01:00.0:reg 0x18: [mem 0x1000ffe00000-0x1000ffffffff 64bit pref] pci 0001:01:00.0:reg 0x20: [io 0xf1051100-0xf10511ff] pci 0001:01:00.0:reg 0x24: [mem 0xc2ffc0000-0xc2fffffff] pci 0001:01:00.0:reg 0x30: [mem 0xc2ffe0000-0xc2fffffff pref] pci 0001:01:00.0:启用扩展标记 pci 0001:01:00.0:支持 D1 D2 pci 0001:01:00.0:D1 D2 D3hot D3cold pci 0001:01:00.0 支持 PME#:可用 PCIe 带宽为 4.000 Gb/s,在 0001:00:00.0 时受 5.0 GT/s PCIe x1 链接限制(使用 8.0 GT/s PCIe x8 链接可达到 63.008 Gb/s) pci 0001:01:00.0:添加到 iommu 组 21 pci 0001:01:00.1:[1002:aae0] type 00 class 0x040300 pci 0001:01:00.1:reg 0x10: [mem 0x1200ffffc000-0x1200ffffff 64bit] pci 0001:01:00.1:启用扩展标记 pci 0001:01:00.1:支持 D1 D2 pci 0001:01:00.1:添加到 iommu 组 21 pci 0001:00:00.0:PCI 桥接到 [总线 01-ff] pci 0001:00:00.0:bridge window [io 0xf1051000-0xf1051fff] pci 0001:00:00.0:桥接窗口 [mem 0xc100000000-0xc1fffff] pci_bus 0001:01:busn _res:[总线 01-ff] 末端更新为 01 pci_bus 0001:00:busn_res:[总线 00-ff] 端已更新为 01 PCI:无法分配设备 0001:00:0 的资源区域 0,将重新映射 PCI:无法分配设备 0001:00:0 的资源区域 2 01:00.0,将重新映射 PCI:无法分配设备 0001:01:00.0 的资源区域 6,将重新映射 PCI:无法分配设备 0001:01:00.1 的资源区域 0,将重新映射 pc i 0001:00:00.0: BAR 0: no space for [mem size 0x01000000] pci 0001:00:00.0:BAR 0:分配失败 [内存大小 0x01000000] pci 0001:00:00.0:BAR 9:无空间 [内存大小 0x00200000 64 位前缀] pci 0001:00:00.0:BAR 9:分配失败 [内存大小 0x00200000 64 位前缀] pci 0001:01:00.0:BAR 2: 已分配 [mem 0xc20000000-0xc201fffff 64bit pref] pci 0001:01:00.0:BAR 6: 已分配 [mem 0xc20200000-0xc2021ffff pref] pci 0001:01:00.1:BAR 0: 已分配 [mem 0xc20220000-0xc20223fff 64bit] pci 0001:00:00.0:PCI 桥接到 [总线 01] pci 0001:00:00.0:bridge window [io 0xf1050000-0xf105ffff] pci 0001:00:00.0:桥接窗口 [mem 0xc100000000-0xc2fffff] pci_bus 0001:00:部分 PCI 设备资源未分配,尝试使用 pci=realloc pci_bus 0001:00 启动:资源 4 [io 0xf105000000-0xf105ffff] pci_bus 0001:00:资源 5 [mem 0xc100000000-0xc2fffff] pci_b us 0001:00:资源 5 [mem 0xc100000000-0xc2fffff fff] pci_bus 0001:01:资源 0 [io 0xf1050000-0xf105fff] pci_bus 0001:01:资源 1 [mem 0xc1000000-0xc2fffff] HugeTLB 注册了 4.00 MiB 页面大小,预先分配 0 页 HugeTLB 注册了 64.0 MiB 页面大小大小,预计 已分配 0 页 HugeTLB 注册了 256 MiB 页面大小,预先分配 0 页 H ugeTLB 注册了 1.00 GiB 页面大小,预先分配 0 页飞思卡尔 Elo 系列 DMA 驱动程序 fsl-elo-dma ffe100300.dma: #0 (fsl,eloplus-dma-channel), irq 28 fsl-elo-dma ffe100300.dma:#1 (fsl,eloplus-dma-channel), irq 29 fsl-elo-dma ffe100300.dma:#2 (fsl,eloplus-dma-channel), irq 30 fsl-elo-dma ffe100300.dma:#3 (fsl,eloplus-dma-channel), irq 31 fsl-elo-dma ffe100300.dma:#4 (fsl,eloplus-dma-channel), irq 76 fsl-elo-dma ffe100300.dma:#5 (fsl,eloplus-dma-channel), irq 77 fsl-elo-dma ffe100300.dma:#6 (fsl,eloplus-dma-channel), irq 78 fsl-elo-dma ffe100300.dma:#7 (fsl,eloplus-dma-channel), irq 79 fsl-elo-dma ffe101300.dma:#0 (fsl,eloplus-dma-channel), irq 32 fsl-elo-dma ffe101300.dma:#1 (fsl,eloplus-dma-channel), irq 33 fsl-elo-dma ffe101300.dma:#2 (fsl,eloplus-dma-channel), irq 34 fsl-elo-dma ffe101300.dma:#3 (fsl,eloplus-dma-channel), irq 35 fsl-elo-dma ffe101300.dma:#4 (fsl,eloplus-dma-channel), irq 80 fsl-elo-dma ffe101300.dma:#5 (fsl,eloplus-dma-channel), irq 81 fsl-elo-dma ffe101300.dma:#6 (fsl,eloplus-dma-channel), irq 82 fsl-elo-dma ffe101300.dma:#7(fsl,eloplus-dma-channel),irq 83 iommu:默认功能域类型:已翻译 iommu:DMA 功能域 TLB 失效政策:严格模式 pci 0001:01:00.0:vgaarb:已添加 VGA 设备:decodes=io+mem,owns=无,locks=none pci 0001:01:00.0: vgaarb: 桥接控制可能 pci 0001:01:00.0:vgaarb:设置为引导设备(VGA 旧版资源不可用) Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955,你能用这个 dts 更改试试吗?:- pci1:pcie@ffe250000 { reg =<0xf 0xfe250000 0 0x10000>; ranges =<0x02000000 0x0 0xe0000000 0xc 0x10000000 0x0 0x20000000 /* 512MB */ 0x01000000 0x0 0x000000 0xf 0xf1050000 0x0 0x00010000> ;/* 64KB I/O */ pcie@0 { ranges =<0x02000000 0x0 0xe0000000 0x02000000 0x0 0xe0000000 0x0 0x20000000 0x01000000 0x0 0x00000000 0x01000000 0x0 0x00000000 0x0 0x00010000>; }; }; Re: PCI memory allocation (BAR Registers) on T1040 Board 嗨 @gaurav_sharma 谢谢你的回复,这个 E9171 AMDGPU 能在 T2080 主板上运行吗? Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 我尝试了这些命令,但得到了相同的错误信息"无效 PCI ROM 头签名:预计为 0xaa55,结果为 0xadde" Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 谢谢你的回复, ,我在配置文件中做了一些改动,就能实现 64 位内核了。现在正在分配内部 BAR(包括 32 位和 64 位)。 但在加载 AMDGPU 驱动程序时,我收到了以下错误信息 root@t1042d4rdb:~# insmod /amdgpu.ko [drm] amdgpu 内核模式设置已启用。 [drm] 初始化内核模式设置(POLARIS12 0x1002:0x6987 0x1787:0x2389 0x80)。 amdgpu 0001:01:00.0:amdgpu:不支持可信内存区域 (TMZ) 功能 [drm] 寄存器 mmio 基础:0x80000000 [drm] 寄存器 mmio 大小:262144 [drm] 不支持 PCIE 原子操作 [drm] 添加 ip 区块编号 0 [drm] 添加 ip 区块编号 1 [drm] 添加 ip 区块编号 2 [drm] 添加编号为 3 的 ip [drm] 添加 ip 区块编号 4 [drm] 添加 ip 区块编号 5 [drm] 添加 ip 区块编号 6 [drm] 添加 ip 区块编号 7 [drm] 添加 ip 区块号 8 amdgpu 0001:01:00.0:无效的 PCI ROM 标头签名:期待 0xaa55,得到 0xadde amdgpu 0001:01:00.0:PCI ROM 标头签名无效:期待 0xaa55,得到 0xadde amdgpu 0001:01:00.0:amdgpu:找不到 BIOS ROM amd gpu 0001:01:00:0 00.0:amdgpu:GPU 初始化期间出现致命错误 amdgpu 0001:01:00.0:amdgpu:amdgpu: amdgpu:amdgpu:amdgpu:am 精加工设备。 尝试在 0x0000000000000000 amdgpu 处取消映射早期的螺栓映射:0001:01:00.0 的探测失败,错误 -22 更新后的设备树如下所示: pci1: pcie@ffe250000 { reg =<0xf 0xfe250000 0 0x10000> ; ranges =<0x02000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000 /* 512MB nonref */ 0x43000000 0xc 0x10000000 0xc 0x10000000 0x0 0x40000000 /* 1GB 64 位前缀 ← 键更改 */ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000> ; pcie@0 { }; }; uBoot 变更: #if! 已定义 (CONFIG_DM_PCI) #define CONFIG_FSL_PCI_INIT /* 使用常用的 FSL 初始化代码 */ #define CONFIG_SYS_PCIE1_MEM_BUS 0xe0000000 #define CONFIG_SYS_PCIE1_MEM_SIZE 0x00000000 CONFIG_SYS_PCIE1_BUS 0x00000000 #define CONFIG_SYS_PCIE1_BUS 0x00000000 CONFIG_SYS_PCIE1_BUS 0x00000000 CONFIG_SYS_PCIE1_IO_BUS PCIE1_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_SYS_PCIE2_MEM_BUS 0xe0000000 #define CONFIG_SYS_PCIE2_MEM_ SIZE 0x100000000 /* 256M */ #define #define CONFIG_SYS_PCIE2_IO_BUS 0x00000000 #define CONFIG_SYS_PCIE2_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_SYS_PCIE3_MEM_BUS #define CONFIG_SYS_PCIE3_IO_BUS CONFIG_SYS_PCIE3_IO_BUS CONFIG_SYS_PCIE3_IO_BUS CONFIG_SYS_PCIE3_IO_BUS 0x00000000 #define CONFIG_SYS_PCIE3_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_SYS_PCIE4_MEM_ BUS 0xe0000000 #define #define CONFIG_SYS_PCIE4_MEM_SIZE 0x100000000 /* 256M */ #define CONFIG_SYS_PCIE4_IO_BUS 0x00000000 #define CONFIG_SYS_PCIE4_IO_SIZE 0x00010000 /* 64k */ #define CONFIG_PCI_INDIRECT_BRIDIGE #endif #define CONFIG_PCI_SCAN_SHOW /* 启动时显示 pci 设备 */ #endif /* CONFIG_PCI */ 对于你的问题,以下是答 案: 1。设备树和 uBoot 中的更改如上所述。 2.附上 pci=realloc 的日志 3.内存大小 = 2GB Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955我想纠正一下之前的说法:- "你的地址 0x1000ffe00000 在 40 多位的范围内,完全超出了 T1040 的寻址空间。" -- 事实并非如此。SOC 的设计适用于高达 64GB 寻址内存空间的大型物理地址空间。假设运行的是 64 位内核 GPU请求的不是地址,只是大小/类型。Linux/ 固件通过对 BAR 编程来分配地址,而你看到的值(如 0x1000ffe00000 )只是当前编程的基数--通常是固件设置错误或 DT 解析错误,直到 Linux 重新分配。 我正在检查为什么会出现这种情况。同时, 1. 你能告诉我除了 dts 之外你在固件/uboot/linux 中是否还有其他与 pcie 相关的更改吗? 2. 你能不能用 pci=realloc 启动一次然后分享日志。 3. 你的主板上的 RAM 大小是多少? Re: PCI memory allocation (BAR Registers) on T1040 Board 当您执行 setpci -s 0001:01:00.0 30.l 时,rom bar 地址编程是否会粘连?执行上述操作后,当您执行以下操作时, :- 。 lspci -vv -s 0001:01:00.0 | grep -i"Expansion ROM" 你看到了什么? 另外,在连续读取多个 devmem 之后:- devmem 0x80040000 16 devmem 0x80040000 16 执行:- lspci -vv -s 0001:00:00.0 | egrep -i"Secondary status|UESta|CESta|AER" dmesg | tail -200 | egrep -i"pcie|aer|abort|error" 你在 dmesg 中观察到任何错误日志吗? Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma ,请查看以下结果, root@t1042d4rdb:~# setpci -s 0001:01:00.0COMMAND=0007 root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l=80040001 root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l 80040001 root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l 80040001 root@t1042d4rdb:~# lspci -vv -s 0001:01:00.0 | grep -i"Expansion ROM" Expansion ROM at 80040000 [size=128K] root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD root@t1042d4rdb:~# lspci -vv -s 0001:00:00.0 | egrep -i"Secondary status|UESta|CESta|AER" Secondary status:66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort- UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- AERCap:第一个错误指针:00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- root@t1042d4rdb:~# dmesg | tail -200 | egrep -i"pcie|aer|abort|error" [ 2.151844] EXT4-fs (mmcblk0p2): warning: mounting fs with errors, running e2fsck is recommended. Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 请查看以下日志 root@t1042d4rdb:~# lspci 0001:00:00.0PCI 桥接器:飞思卡尔半导体公司设备 0820(修订版 10)0001:01:00.0 兼容 VGA 的控制器:Advanced Micro Devices, Inc. [AMD/ATI] Lexa [Radeon 540X/550X/630/RX 640/E9171 MCM](修订版 80) 0001:01:00.1 音频设备:高级微设备公司 [AMD/ATI] Baffin HDMI/DP 音频 [Radeon RX 550 640SP/RX 560/560X] root @t1042d4rdb ~# root @t1042d4rdb:~# root @t1042d4rdb:~# lspci-vv-s 0001:01:00.0 0001:01:00.0兼容 VGA 的控制器:Advanced Micro Devices, Inc. [AMD/ATI] Lexa [Radeon 540X/550X/630/RX 640/E9171 MCM](修订版 80)(prog-if 00 [VGA 控制器]) 子系统:高科技信息系统有限公司设备 2389 控制:I/O+ Mem+ BusMaster+ SpecCycle-memwinv-vgasNoop-ParerR-步进 SERR-FastB2b-disintX-状态:Cap+ 66MHz-UDF-FastB2b-Parerr-devsel=Fast > tabort-< tabort- SERR-SERR- < PERR-INTX- 延迟:0,缓存行大小:32 字节 中断:引脚 A 路由到 IRQ 41 IOMMU 组:21 区域 0:c1000000 处的内存(64 位,可预取)[size=256M] 区域 2:c200000(64 位,可预取)的内存 [size=256] 区域 4:1100 的 I/O 端口 [size=256] 区域 5:内存在 80000000(32 位,不可预取)[size=256K] 扩展 ROM 为 80040000 [已禁用] [size=128K] 功能:[48] 供应商特定信息:Len=08 <? > 功能:[50] 电源管理单元 版本 3 标志:pmeClk-DSI-D1+ D2+ auxcurrent=0mA PME(D0-、D1+、D2+、d3Hot+、d3Hot+、d3Cold+) 状态:D0 nosoftRST+ PME-enable-dsel=0 pme- 功能:[58] Express (v2) 传统端点,MSI 00 DevCa p:maxPayload 256 字节,PhantFunc 0,延迟 l0s < 4us,L1 无限制 extTag+ attnBtn-attnn-attnnInd-pwrind-RBE+ flreset-devCtl:correrr-nonFatalerr-Fatalerr-Unsuperq-rlxDord+ extTag+ phantFunc-auxPWR-noSnoop+ maxPayload 128 字节,maxReadReq 512 字节 devSta:correrr+ nonfatalerr-Fatalerr-Unsupreq+ auxPWR-TransSpend-LnkCap:端口 #0,速度 8GT/s,宽度 x8,ASPM L1,退出延迟 L1 < 1us clockPM+ 惊喜-llactrep-bwnot-aspmoptComp + lnkCt l:ASPM 禁用;RKCtl:ASPM 已禁用;CB 64 字节,禁用-commCLK-extSynch-clockPM-autWiddis-bwint-AutbWint-lnkSta:速度 5GT/s(降级),宽度 x1(降级)trerr-Train-slotCLK+ dLActive-bwint-devCap2:完成超时:不支持, Timeoutdis-nroprp-LTR+ 10bittagComp-10bittagReq-OBFF 不支持,extFMT+ eetlpPrefix+、maxeetLPPrefix+ 1 不支持紧急 功率降低,紧急降电init-FRS-AtomicopsCap:32 位+ 64 位+ 128 bitcas-d evctl2:完成超时:50 us 到 50 毫秒,TimeoutDis-LTR-OBFF 已禁用,At omicopSCTL:reqen-lnkCap2:支持的链路速度:2.5-8GT/ s,Crosslink-重定时器-2重定时器-DRS-lnkCtl2:目标链路速度:8GT/s,EnterCompanial-SpeedDis-传输余量:正常工作范围, 进入修改后的合规性-合规性操作系统-合规性减重:-6dB Lnksta2:当前去加重级别:-6dB,均衡完成- 均衡阶段 1-均衡阶段 2-均衡阶段 3-LinkEqualizationRequest-重定时器-2 重定时器-Crosslinkres:不支持的功能:[a0] MSI:启用-计数 =1/1 可屏蔽-64 位 + 地址:0000000000000000 数据:0000 能力:[100 v1] 供应商特定信息:ID=0001 Rev=1 Len=010 功能:[150 v2] 高级错误报告 uestA:DLP-SDES-TLP-FCP-cmplto-cmplto-cmplt-unxcmplt-rxof-MalftLP-ECRC-Unsupreq-acsviol-uemsk:DLP-SDES-TLP-FCP-cmpltto-cmplt-unxcmplt-ECRC-Unsupreq-acsviol- uemsk:DLP-SDES-TLP-FCP-cmpltto-cmpltbrt-unxcmplLP-ECRC-Unsupreq-acsviol-uesVRT:DLP+ SD ES+ TLP-FCP+ cmplto-cmplto-cmplt-rxOf+ malftLP+ ECRC-Unsupreq-acsViol-cesta:rxerr-badtlp-baddlp-baddLPLP-Timeout-rxof+ malftLP+ ECRC-Unsupreq-acsViol-cesta:rxerr-badtlp-baddllp-rolver-Timeout-advnonFatalerr+ AerCap:第一个错误 指针:00,ecrcgencap+ ecrcGenenen-ecrcchken+ ecrcchken-multhDrrecca p-multhDrrecen-tlppfxPres-HdrlogCap-He aderLog:00000000 00000000 00000000 能力:[200 v1] 物理大小可调整的 BAR 0:当前大小:256MB 512MB 1GB 2GB 4GB 容量:[270 v1] 辅助 PCI Express lnkCtl3:lnkequintrrupten-PerformeQu-LaneerrStat:0 功能:[2b0 v1] 地址映射 服务 (ATS) atsCap:无效队列深度:00 atsCTL:启用-,最小转换单位:00 功能:[2c0 v1] 页面请求接口 (PRI) pr icTL:启用-RESET-p rista:RF-UPRGI-Stoped+ 页面请求容量:00000020,页面请求分配:00000000 功能:[2d0 v1] 进程地址空间 ID (PASID) p asidCap:Exec+ Priv+,最大 PASID宽度:10 pasidCtl:启用-执行-Priv-功能:[320 v1] 延迟容差报告最大监听延迟:0 ns 最大无窥探延迟:0 ns 功能:[328 v1] 替代 路由 ID 解释 (ARI) ariCap:MFVC-ACS-,下一个函 数:1 aricTL: MFVC-ACS-,功能组:0 能力:[370 v1] L1 PM Substates L1subcap:PCI-PM_L1.2+ PCI-PM_L1.1+ASPM_L1.2+ASPM_L1.1+L1_PM_Substates+ PortCommonModeRestoreTime=0us PortTPowerOnTime=170us L1SubCtl1:PCI-PM_L1.2-PCI-PM_L1.1-ASPM_L1.2-ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2:T_PwrOn=10us 内核模块:amdgpu root@t1042d4rdb:~# lspci -vv -s 0001:00:00.0 0001:00:00.0PCI 桥接器:飞思卡尔半导体公司设备 0820(修订版 10)(prog-if 00 [正常解码]) 设备树节点:/sys/固件/devicetree/base/pcie @ffe250000 /pcie @0 控制:I/O+ Mem+ BusMaster+ SpecCycle-memware-Vgasnoop-Parerr-Steping-Serr+ FastB2b-disintX-状态:Cap+ 66MHz-UDX-UDCLE-memware-VGasnoop-Parerr-Steping-Serr+ FastB2b-disintX-状态:Cap+ F-fastB2b-Parerr-devsel=Fast > taBort-< taBort- SERR-< PERR-intX- 延迟:0,缓存行大小:32 字节 中断:引脚?路由到 IRQ 21 IOMMU 组:21 区域 0:已忽略 (32 位,不可预取) 总线:primary=00,secondary=01,subordinate=01,sec-latency=0 I/O behind bridge: 00000000-0000ffff [size=64K] Memory behind bridge: 80000000-8fffffff [size=256M] Prefetchable memory behind bridge: 0000000c10000000-0000000c4fffffff [size=1G] Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >RESET- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] 电源管理单元 version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [4c] Express (v2) Root Port (Slot-), MSI 00 DevCap: MaxPayload 256 字节, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr+ FatalErr+ UnsupReq+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 字节, MaxReadReq 512 字节 DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s, Exit Latency L0s <2us ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 字节, Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s (ok), Width x1 (downgraded) TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt+ RootCap: CRSVisible- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- DevCap2: Completion Timeout: Range ABC, TimeoutDis+ NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- AtomicOpsCtl: ReqEn- EgressBlck- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 RootCmd: CERptEn- NFERptEn- FERptEn- RootSta: CERcvd- MultCERcvd- UERcvd- MultUERcvd- FirstFatal- NonFatalMsg- FatalMsg- IntMsg 0 ErrorSrc: ERR_COR: 0000 ERR_FATAL/NONFATAL: 0000 Kernel driver in use: pcieport root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l fffe0000 Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955请粘贴这些命令的输出结果: - lspci-vv -s 0001:01:00.0 lspci -vv -s 0001:00:00.0 setpci -s 0001:01:00.0 30.l Re: PCI memory allocation (BAR Registers) on T1040 Board @Ganesh3955 lspci 日志显示:- 扩展 ROM: 80040000 [禁用] 大小 128KB(Linux 根据 BAR 类型/大小分配资源) Linux 打算让 ROM 在 0x80040000 的低非前置窗口中运行,这是件好事,也是众望所归。这表明 ROM 在已编程窗口的范围内。 "root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l fffe0000" -- 这看起来像一把冒烟的枪。 0xfffe0000 正是探测 128KB ROM BAR 时得到的大小掩码(128KB = 0x20000;掩码清除低 17 位 → 0xfffe0000 )。这是在写入所有 1 以检测 ROM 大小后通常读回的值。 它不包含有效地址,而是包含 "大小探测掩码"。 因此,ROM BAR 编程/启用路径存在问题。 看来是固件(uboot)或早期的 pci 代码在探测内存大小,而没有恢复内存条基数。 您能否尝试对 ROM 条形底座进行强制编程,并通过执行以下操作启用它:- # 确保 MEM 解码已启用 setpci -s 0001:01:00.0命令=0007   # 现在我们知道 linux 分配的 ROM 地址是 0x80040000 setpci-s 0001:01:00.0 30.l=80040001 然后使用以下方法读取字节:-d evmem 0x8004000 0 16 有效的 rom 应以字节 55 aa 开头,这是我们期望从上面观察 到的。 如果有效,您可以再次尝试 sysfs rom dump:- echo 1 > /sys/bus/pci/devices/0001:01:00.0/rom dd if=/sys/bus/pci/devices/ 0001:01:00.0 /rombs=1 count=16 2>/dev/null | hexdump -C echo 0 > /sys/bus/pci/devices/0001:01:00.0/rom Re: PCI memory allocation (BAR Registers) on T1040 Board 你好@gaurav_sharma 我得到的结果如下, root@t1042d4rdb:~# setpci -s 0001:01:00.0COMMAND=0007 root@t1042d4rdb:~# setpci -s 0001:01:00.0 30.l=80040001 root@t1042d4rdb:~# devmem 0x80040000 16 0xDEAD
記事全体を表示
[紧急] S32N55 安全调试实现 - SDAF volkano.exe 问题和 HSE2 FW RM 请求 亲爱的恩智浦支持团队 我目前正在进行一个涉及 S32N55 平台的客户项目,交付时间紧迫,我迫切需要您就以下与安全调试实施相关的主题提供支持。如能及时回复,将不胜感激。 --- [主题 1] SDAF volkano.exe - 无法加载加密库 环境: -TRACE32 软件包:trace32_n_2026_04_000189919_nxp_s32n55_conf-SDAF 版本:1.1.0RTM - 主机操作系统:Windows 10 x64 症状: 所有 volkano.exe 命令(如generate_wrapkey, discover)失败,并伴有以下错误: **error** 无法加载加密库 已采取的步骤: - 复制 libeay32.dll 和 ssleay32.dll (OpenSSL 1.0.2sWin64) 放入 sdaf 文件夹 -已确认 VC++ 2017 可再发行版 (14.16.27052) 已安装-已确认 volkano.exe 是 64 位二进制文件 问题: 1.运行 volkano.exe 还需要任何额外的 DLL 或中间件吗? 2。volkano.exe 是否必须使用物理智能卡和读卡器才能运行? 3.如果需要智能卡,能否请您就兼容的智能卡型号和中间件安装程序提供建议? 4。有没有办法在没有智能卡的情况下在本地存储模式下使用 volkano.exe 进行开发? --- [主题 2] 安全调试实施-ADKP 配置和质询/响应流程 对于我们的客户项目,我们正在使用具有质询/响应 (C/R) 授权模式(HSE_OWNER_DEBUG_AUTH_CR,默认模式)的 FSS 调试功能域在 OEM_CLOSED 生命周期中为 S32N55 实施安全调试。 我们目前对流程的理解如下: 1.通过 HSE2 setAttribute (HSE_OTP_FOEM_ADKP_ATTR_ID) 向 OTP 熔丝配置 ADKP(32 字节对称密钥) 2.将生命周期提前到 OEM_CLOSED 3.在调试时,TRACE32 通过 Chip.secureChallenge () 4 读取 UID 和 256 位质询。volkano.exe 使用预置的 ADKP 5 计算响应。 TRACE32 通过 System.OPTION 键码连接 问题: 1.你能否确认 S32N55 FSS 安全调试的上述流程是正确的吗? 2。用于计算 ADKP 和 Challenge 的 C/R 响应的确切加密算法是什么?例如AES-ECB) 3。除 ADKP 配置外,是否需要任何其他配置(例如FOEM_Debug_Auth_Mode 熔丝设置) 以启用 C/R 模式? 4。安全调试是否需要 MCK(HSE_OTP_FOEM_MCK_ATTR_ID)? 5。能否分享一下 S32N55 的 HSE2 固件参考手册,特别是涵盖安全调试挑战/响应算法和 ADKP 配置详细信息的章节?我们知道 HSE-H/M RM 中可能记录了 C/R 响应计算算法(如 S32G2 的情况),但我们不确定同样的算法是否适用于 S32N55 HSE2。如能就这一点作出澄清,将不胜感激。 这是客户项目交付的关键障碍。如蒙尽早回复,我们将不胜感激。 致以最诚挚的问候, Eddie Park Re: [URGENT] S32N55 Secure Debug Implementation - SDAF volkano.exe Issue and HSE2 FW RM Request 你好,@EddiePark、 感谢您联系我们。我理解你的问题的紧迫性,因此我想明确表示,我无法在有关 S32N55 的所有方面为您提供帮助,因为它是预生产芯片,在恩智浦社区中,我们只能在全面发布的产品方面为您提供帮助。您可以联系恩智浦代表/代理商,获取有关该主题的更多帮助。 此外,我不知道使用 TRACE32 进行安全调试的程序,但我可以分享这篇文章,其中介绍了如何使用 S32 Design Studio 进行调试。不过,由于 S32N55 芯片较新,操作步骤可能会有些不同,我无法提供上述明确信息。您还可以查看与此话题类似的其他对话。 如需更好的 TRACE32 支持,我建议您并行联系lauterbach。 请注意,我无法测试 ADKP 功能,因为我无权修改我们拥有的测试板的任何 OTP 配置。 如果还需要其他帮助,请告诉我。
記事全体を表示
What Are the Best IPTV Providers in 2026? The way people watch television has changed faster than ever. Cable bills keep rising, viewers want more flexibility, and streaming has become the new normal. That is why many users now ask, What Are the Best IPTV Providers in 2026? They want better channel choices, smoother playback, and access to entertainment without the limits of traditional TV. 🛰️ Explore Best IPTV Providers IPTV stands for Internet Protocol Television. It delivers live TV channels, movies, sports, and on-demand content through an internet connection. Instead of using satellite or cable lines, users stream content directly on Smart TVs, Firestick, Android devices, tablets, and laptops. In 2026, IPTV services continue to grow because they offer convenience, value, and modern viewing features. This guide explains what makes a provider stand out and how to find the best IPTV solution for your needs. What Are the Best IPTV Providers in 2026 Known For? The best IPTV providers in 2026 are not only about having many channels. Quality matters more than quantity. A top provider should deliver stable streams, easy navigation, and strong customer support. Reliable IPTV services invest in better servers to reduce buffering. They also refresh channel lists regularly and maintain smooth access during busy hours. This is especially important for sports fans and live event viewers. Another sign of a strong provider is a user-friendly setup process. Good IPTV platforms make activation simple and compatible with popular apps and streaming devices. Why IPTV Is More Popular in 2026 Many households now prefer streaming because it matches modern lifestyles. Users want entertainment on their schedule, not fixed cable packages. Flexible Viewing on Any Device One major reason IPTV is growing is device freedom. Users can switch between Smart TVs, phones, tablets, and streaming sticks with ease. This creates a seamless entertainment experience. Better Value Than Traditional TV Many people search for affordable IPTV providers because they want more content without paying high monthly cable fees. IPTV often includes global channels, sports, and movies in one package. On-Demand Convenience Viewers no longer want to wait for scheduled broadcasts. IPTV often offers replay options, catch-up TV, and video-on-demand content that fits busy routines. Key Features of the Best IPTV Providers in 2026 Choosing the right service becomes easier when you know what to look for. Stable Streaming Quality The best IPTV providers in 2026 focus on fast servers and high uptime. Smooth playback matters more than long channel lists that do not work properly. Broad Channel Selection Top providers often include entertainment, news, sports, kids content, and international networks. A balanced lineup gives more value to subscribers. HD and 4K Support Many users now expect high-resolution streaming. Premium IPTV services often include HD, Full HD, and 4K options for supported channels. Responsive Customer Support Fast support helps when login issues, setup errors, or app problems happen. Reliable customer service is a major factor when choosing an IPTV provider. How to Choose the Best IPTV Provider for You Every viewer has different priorities. Some want sports coverage, while others focus on movies or family entertainment. If live sports matter most, look for stable event streams and wide sports channel coverage. If you enjoy films and series, choose a provider with a strong VOD library and updated content. Families may prefer multi-device access and children’s channels. Travelers may want worldwide compatibility and flexible login options. Testing before subscribing is also wise. Many users search for IPTV free trial services to check quality before purchasing a long plan. SEO Trends Driving IPTV Searches Search phrases like best IPTV providers in 2026, top IPTV services, premium IPTV plans, and no buffering IPTV are becoming more common. This reflects growing demand for flexible streaming solutions. As internet speeds improve worldwide, IPTV becomes easier to use. Smart TVs and streaming devices are also more affordable, which helps IPTV adoption rise. People want personalized entertainment, and IPTV gives them more control than standard television packages. Mistakes to Avoid When Choosing IPTV Some users choose only the cheapest option. Low prices can be attractive, but poor stream quality and weak support may lead to frustration. Another mistake is ignoring compatibility. Always confirm the provider works on your preferred device. Skipping research can also cause problems. Reading recent reviews and testing a trial can help avoid unreliable services. The Future of IPTV in 2026 IPTV is expected to become smarter and more user-focused. Faster networks, improved apps, and better content libraries will continue to shape the market. Many providers are improving interfaces, search tools, and streaming stability. This means users can expect smoother experiences in the future. As demand rises, competition among IPTV providers may also improve pricing and service quality. Conclusion So, What Are the Best IPTV Providers in 2026? They are the services that combine stable streaming, quality content, easy setup, and strong support. The best option depends on your viewing habits, devices, and budget. When choosing an IPTV provider, focus on performance rather than promises. A service with reliable playback and useful features will always offer better value. If you are ready to upgrade your entertainment experience, explore trusted IPTV providers and enjoy smarter streaming in 2026. Re: What Are the Best IPTV Providers in 2026? Looking for the best way to enjoy premium content without an immediate commitment? In 2026, the most effective way to find a high-quality provider is through a free IPTV trial. Why Start with a Free Test? A free trial allows you to verify several critical factors before subscribing: Stability: Ensure the service offers buffer-free streaming and high uptime (ideally 99% or more). Content Variety: Check for access to over 20,000+ live channels, including premium sports, news, and international networks. Quality: Verify support for HD, Full HD, and 4K streaming. Device Compatibility: Confirm it works on your preferred hardware, such as Amazon Firestick, Smart TVs, Android/iOS devices, or PCs. Top Recommendation for 2026 For a premium experience with a vast selection of channels and reliable performance, we recommend testing GoldCard TV. It is designed to provide a seamless entertainment solution with minimal downtime. 👉 Start your free trial now at: https://omeulink.com/GoldCardTv Re: What Are the Best IPTV Providers in 2026? I’ve tested several IPTV providers over the past few months, and in my experience, HypoTV is one of the best overall for stability, streaming quality, and everyday entertainment. If you’re looking for sports-focused streaming, BekuTV performs really well with smooth live channels and minimal buffering. For adult content and large VOD libraries, PillowIPTV is a strong option. I’ve also seen many users recommend MomIPTV for its reliable international channel selection and multi-device support. Overall, each service has its strengths depending on what type of content you watch most. Re: What Are the Best IPTV Providers in 2026? I’ve tested many IPTV services, and NexusIPTV honestly surprised me with its stability and picture quality. Fast channels, almost no buffering, and a huge selection of sports, movies, and international content in HD/4K. Works perfectly on Firestick, Smart TVs, Android, iPhone, and PC. If you want a reliable IPTV service in 2026, NexusIPTV is definitely worth trying. www.nexusiptv.live  Re: What Are the Best IPTV Providers in 2026? I’ve tested a few services recently mainly for live sports, and UHDSports has honestly been one of the smoother ones so far. What I liked most is that it didn’t feel overloaded or messy. The setup was simple, the channels opened quickly on my device, and the sports streams were stable during peak hours, which is usually where most providers start buffering. I also tested it on a Smart TV and Android device, and both worked fine. The VOD side is decent too, but for me the main reason to use it is live sports. If you’re choosing a provider, I’d still recommend asking for a free trial first and testing it during an actual live match, not just during quiet hours. That’s the real test. Not saying it’s perfect, but from my experience UHDSports is worth checking if your priority is stable live sports and quick support. Re: What Are the Best IPTV Providers in 2026? If you’re tired of hunting for links, switching apps, or dealing with lag during big matches, tvaccess.xyz is the platform built for you. This premium paid service delivers every major sport in the world — all in HD, Full HD, and 4K Ultra Quality with smooth, stable streaming. Watch every sport live in HD/4K tvaccess.xyz Re: What Are the Best IPTV Providers in 2026? I agree that choosing an IPTV provider in 2026 really comes down to reliability, channel selection, and streaming quality. I also like services that make it easy to verify information before making a decision. For unrelated research, I recently found Franklin Property Data useful for checking property related details. It’s always worth comparing options carefully and choosing a service that fits your needs.
記事全体を表示
Best IPTV Service 2026 best IPTV service in 2026 is IPTVProvider.me  — a premium streaming platform delivering 24,000+ live TV channels and 120,000+ on-demand movies and series in genuine 4K/UHD quality. Powered by proprietary anti-freeze technology that maintains 99.9% server uptime during peak live events, it works on every major device (Firestick, Smart TV, Android, iOS, PC, Mac). Plans start at $7.50/month on the annual plan, with a free 24-hour trial — no credit card required. As of April 2026, 50,000+ verified subscribers rate the service 4.9/5 🔗 Official site: https://www.iptvprovider.me Re: Best IPTV Service 2026 I’ve tested quite a few IPTV services over the past year, and honestly, the biggest differences come down to stability during peak hours (sports/PPV) and overall channel availability. One service that’s been pretty solid for me recently is Pillow IPTV. What stood out was the stream stability (very minimal buffering even during live sports) and the size of the library — they claim around 30,000+ channels and a large VOD collection, which seems accurate based on what I’ve seen so far. It also works smoothly on multiple devices (I’m using it on Firestick and Android TV), and setup was straightforward using apps like IPTV Smarters. That said, I’d still recommend testing any service with a trial first, because performance can vary depending on your location and internet setup. Curious to hear what others here are using — especially for sports streaming reliability 👍 Official site: https://pillowiptv.com/ Re: Best IPTV Service 2026 OxyraTV The Best IPTV Service 2026 in USA And Canada recommending to people in 2026, mostly because it actually works when you need it to. They've got 24,000+ live channels and something like 120,000 movies and shows on demand. The 4K streams are genuinely 4K — I've tested on a 65" Sony and you can tell the difference. Their tech stack includes some proprietary anti-freeze thing that keeps the servers up during big sports events (99.9% uptime, they claim). Official Site is www.oxyratv.com. Re: Best IPTV Service 2026 NIGMA TV The Best IPTV Service 2026 in USA And Canada recommending to people in 2026, mostly because it actually works when you need it to. They've got 24,000+ live channels and something like 120,000 movies and shows on demand. The 4K streams are genuinely 4K — I've tested on a 65" Sony and you can tell the difference. Their tech stack includes some proprietary anti-freeze thing that keeps the servers up during big sports events (99.9% uptime, they claim). Official Site is www.nigma.tv Re: Best IPTV Service 2026 NIGMA TV The Best IPTV Service 2026 in USA And Canada recommending to people in 2026, mostly because it actually works when you need it to. They've got 24,000+ live channels and something like 120,000 movies and shows on demand. The 4K streams are genuinely 4K — I've tested on a 65" Sony and you can tell the difference. Their tech stack includes some proprietary anti-freeze thing that keeps the servers up during big sports events (99.9% uptime, they claim). Official Site is NIGMA .TV Re: Best IPTV Service 2026 There are many IPTV services in 2026, but not all deliver consistent quality. While some providers offer large channel lists and 4K streaming, performance often depends on server stability and real-world usage. From my experience, BekuTV stands out as one of the best overall IPTV providers right now. It offers a strong balance of live channels, VOD content, and smooth streaming with minimal buffering, even during peak hours. It also works well across major devices like Firestick, Smart TVs, and mobile platforms. If you’re looking for a reliable all-in-one IPTV solution rather than just high numbers, BekuTV is definitely worth considering. Visit to learn more: bekutv.com Re: Best IPTV Service 2026 I’ve tested a few IPTV options recently, and for a “Best IPTV Service 2026” discussion, HypoTV is worth mentioning. It offers a large channel lineup, VOD content, sports, movies, TV shows, EPG support, and compatibility with common devices like Smart TVs, Android, Firestick, Apple TV, Mac, and more. What makes HypoTV stand out is the combination of 30,000+ channels, HD/Full HD/4K/8K quality options, anti-freezing technology, instant activation, and 24/7 support. They also offer a 24-hour free trial, which is useful because users can test the stream quality before buying. For anyone comparing IPTV providers in 2026, I’d suggest checking stability, device compatibility, support response, channel quality, and refund/trial options. Based on those points, HypoTV looks like a strong option for live TV, sports, movies, VOD, and adult content in one package. HypoTV Official Website: https://hypotv.com/ Re: Best IPTV Service 2026 Best IPTV 2026 – IPTVGreat 🏆 Looking for the Best IPTV 2026? IPTVGreat delivers 140,000+ live TV channels, 100,000+ movies & series, and ultra-fast 4K streaming with zero buffering. Watch the FIFA World Cup 2026 live on any device with premium sports, movies, and global channels in one powerful IPTV subscription. Get Now Best IPTV Provider : https://iptvgreat.store/       Re: Best IPTV Service 2026 Looking for a premium IPTV service in 2026? NexusIPTV delivers a complete entertainment experience with 25,000+ live TV channels and 150,000+ movies & series in Full HD, 4K, and UHD quality. Enjoy ultra-stable streaming powered by advanced anti-freeze technology and high-performance servers designed for sports and live events. Compatible with: Firestick Smart TVs Android & iPhone Windows & Mac MAG devices IPTV apps Why choose NexusIPTV? ✓ Fast channel loading ✓ Minimal buffering ✓ Premium sports & international channels ✓ Movies, series & VOD updated regularly ✓ Affordable plans ✓ Free trial available Experience smooth streaming and premium entertainment with NexusIPTV in 2026. https://www.nexusiptv.live/ Re: Best IPTV Service 2026 Ipcanadatv.com The Best IPTV Service 2026 in USA And Canada recommending to people in 2026, mostly because it actually works when you need it to. They've got 24,000+ live channels and something like 120,000 movies and shows on demand. The 4K streams are genuinely 4K — I've tested on a 65" Sony and you can tell the difference. Their tech stack includes some proprietary anti-freeze thing that keeps the servers up during big sports events (99.9% uptime, they claim). Official Site is www.ipcanadatv.com. Re: Best IPTV Service 2026 Ipplaytv.com The Best IPTV Service 2026 in USA And Canada recommending to people in 2026, mostly because it actually works when you need it to. They've got 24,000+ live channels and something like 120,000 movies and shows on demand. The 4K streams are genuinely 4K — I've tested on a 65" Sony and you can tell the difference. Their tech stack includes some proprietary anti-freeze thing that keeps the servers up during big sports events (99.9% uptime, they claim). Official Site is www.ipplaytv.com.
記事全体を表示
MC9S12A32のデバッグモードの不具合とEEPROMのフラッシュに関する質問 こんにちは、 現在、68HC11 をベースにした製品の移植作業を行っており、古い 9S12 マスクを再導入するパッチを適用した CodeWarrior 5.9.0 上で MC9S12A32 を使用しています。私もPEmicroの最新ファームウェアを搭載したP&Eマルチリンクrev.Cを使用しています。私はこれらのチップを扱うのはまだ始めたばかりなので、もし何か間違ったことを言っていたら申し訳ありません。 チップに書き込む方法によって、動作がおかしくなることがあります。以下に説明します。 「デバッグ」ボタンを点滅させる 例: JSR 0x468D 0x468D では、期待されるバイトは 4E に続いて 01 01 FB B6 11 となります。 実際には、47 の後に 1F 5F 48 06 22 が続きます .s19をフラッシュするHC12MultilinkCyclonePro->Load...(デバッグウィンドウ内)からファイルをダウンロードします。 JSR 0x468D、次の6バイトは正しいです。 さらに、.s19でフラッシュした後ファイルを実行すると、プログラムが数秒後にフリーズするようです(メインタスクループ内のXOR GPIOトグルをオシロスコープに接続して確認しました)。 デバイスの電源を入れ直すと、この現象は発生せず、問題なく動作します。 最後に、.s19ファイルにはEEPROMアドレスブロックが含まれていないようです。MC9S12A32のEEPROMをどのようにプログラムすればよいでしょうか? ご回答をお待ちしています。
記事全体を表示
RT1052的DCD文件SDRAMCR0与SEMC_DBICR0两个寄存器配置矛盾 尊敬的NXP:        您们好!        RT1052开发板SDK(D:\SDK_2_14_0_MIMXRT1052xxxxB\boards\evkbimxrt1050\lvgl_examples\lvgl_demo_widgets\mdk)中,dcd.c文件中,有两个寄存器的配置: ① /* #1.104, command: write_value, address: SEMC_SDRAMCR0, value: 0xF07, size: 4 */ 0x40, 0x2F, 0x00, 0x40, 0x00, 0x00, 0x0F, 0x07, COL:11b - 9 bit 9-8 COL Column address bit number 00b - 12 bit 01b - 11 bit 10b - 10 bit 11b - 9 bit 这个寄存器配置Column address bit number为9bit。 ②  /* #1.108, command: write_value, address: SEMC_DBICR0, value: 0x21, size: 4 */ 0x40, 0x2F, 0x00, 0x80, 0x00, 0x00, 0x00, 0x21, COL:0000b - 12 Bits 15-12 COL Column Address bit width 0000b - 12 Bits 0001b - 11 Bits 0010b - 10 Bits 0011b - 9 Bits 0100b - 8 Bits 0101b - 7 Bits 0110b - 6 Bits 0111b - 5 Bits 1000b - 4 Bits 1001b - 3 Bits 1010b - 2 Bits 1011b - 12 Bits 1100b - 12 Bits 1101b - 12 Bits 1110b - 12 Bits 1111b - 12 Bits Column Address bit width被设置为12bit。 这两个寄存器配置是不是矛盾?还是我的理解有问题?        此致 敬礼! Re: RT1052的DCD文件SDRAMCR0与SEMC_DBICR0两个寄存器配置矛盾 Hi @FromCH0 , 感谢您关注恩智浦RT系列产品,很高兴为您服务。 Q: 这两个寄存器配置是不是矛盾?还是我的理解有问题? A:  这两个设置不矛盾。  1: SEMC_SDRAMCR0 用于 SDRAM 地址复用/映射,决定 Column,Bank 等地址位的组织方式,并作用 Row 地址设置。  2:SEMC_DBICR0 是 SEMC 的 DBI-B 控制寄存器,属于 Display Bus Interface 控制功能,不参与 SDRAM 地址映射,所以两者寄存器不会发生冲突。     希望以上对您有帮助 Best Regards May Liu Re: RT1052的DCD文件SDRAMCR0与SEMC_DBICR0两个寄存器配置矛盾 RT1052 的 SEMC_DBICR0 目前能可靠确认的核心用途是配置 SEMC 的 DBI-B/8080 显示总线位宽( for example :8 位或 16 位),它不参与 SDRAM 映射,时序细节主要应在 DBICR1 中配置。 Re: RT1052的DCD文件SDRAMCR0与SEMC_DBICR0两个寄存器配置矛盾 我大概理解了您的意思。可是,SEMC_DBICR0是配置Display Bus Interface 控制功能,具体怎么来配置这个寄存器呢?RT1052的参考手册上关于这个寄存器的说明不多的。SEMC_SDRAMCR0这个寄存器的配置倒是好理解,查找SDRAM的DATASHEET,对应起来就是。 Re: RT1052的DCD文件SDRAMCR0与SEMC_DBICR0两个寄存器配置矛盾 您也是NXP的雇员。您拿不到SEMC_DBICR0寄存器的详细资料?昨天参加您们的一个会议,您们NXP的中国团队的技术工程师,也会觉得掌握RT系列MCU会有难度?
記事全体を表示
在 Android 11 中无法玩 Unity 3D 游戏 亲爱的团队 我使用 Unity Hub 和安卓运行时开发了一款 3D unity 游戏。我可以在基于 Android 的手机上玩游戏,但无法在 iMX8QM 上玩同样的游戏。而且似乎没有特定的错误日志 1.iMX8QM 安卓平台支持 3D 游戏吗? 2.如果是,我们是否需要额外添加一些东西来启用 3D 游戏? 顺祝商祺! 利宾-何塞 Re: Unable to play unity 3D games in Android 11 嗨,利宾、 i.MX8QM 可以支持 3D 游戏,但通常需要适当的 GPU 驱动程序和图形 API 支持(OpenGL ES 或 Vulkan)。确保驱动程序已更新,检查 Unity Player 图形设置,查看 logcat 是否有隐藏警告。先测试一个简单的场景可以帮助确定是一般 3D 问题还是游戏中的特定问题。 Re: Unable to play unity 3D games in Android 11 在GuauMod.io,数以千计的安卓免费游戏为您提供多种类型的娱乐。 Re: Unable to play unity 3D games in Android 11 当我想补充收入时,我发现利用技能或爱好是一个很好的开始。例如,如果你喜欢平面设计,在 Fiverr 或 Upwork 等平台上从事自由职业可能是一个可行的选择。 Re: Unable to play unity 3D games in Android 11 您可以玩一些越野赛车游戏来娱乐自己。你可以试试Hill Climb Racing MOD APK,免费为你提供娱乐。 Re: Unable to play unity 3D games in Android 11 你指的是 iMX8QM平台上的安卓手机/安卓系统吗? Re: Unable to play unity 3D games in Android 11 嘿,利宾!实际上,我在安卓手机上尝试玩 Unity 3D 游戏时也遇到了同样的问题。这让我非常沮丧,因为我也不知道问题出在哪里。至于你提出的有关 iMX8QM 的问题,我不太清楚该平台是否支持 3D 游戏,或者是否还需要启用其他功能。您是否尝试过联系他们的支持团队或论坛,看看是否有其他人遇到过类似问题?我还在找一些新游戏玩。实际上,我今天早些时候正在查看一些泡泡现金的评论,看看是否值得一试。你听说过这件事吗? Re: Unable to play unity 3D games in Android 11 嗨,卢西奥、 日志中没有任何错误。因此,我认为这是一个平台问题。不过,我修改了 Unity 设置,使用 OpenGL ES 3.2 版本,并重新编译了应用程序。然后,我在 iMX8QM 上重新安装了这个新的应用程序,但问题依然存在。不过,这一次我可以开始游戏了。但演出效果太差了。所以我猜测可能是因为我开发的游戏地形复杂,而 iMX8 无法渲染地形。 然后,我尝试安装一些第三方简单游戏。这次我可以玩游戏了,但与在 PC 上渲染的同款游戏相比,渲染效果并不理想。 @nxp,请优先考虑这个问题。您的平台方面肯定存在图形问题。 顺祝商祺! 何塞 Re: Unable to play unity 3D games in Android 11 我也遇到了同样的问题。到目前为止,您找到任何解决方案了吗? Re: Unable to play unity 3D games in Android 11 嘿,Libin,我以前也遇到过类似的情况。iMX8QM 确实支持 OpenGL ES,但 Unity 3D 游戏对图形应用程序接口很挑剔。我要检查的第一件事是你的 Unity 版本是设置为 OpenGL ES 3.0 还是 Vulkan —— imx8QM 上的某些配置在 Vulkan 中不能很好地运行,所以试着在播放器设置中强制 OpenGL ES 看看这是否有区别。 此外,还值得检查 iMX8QM Android 映像上的 GPU 驱动程序是否完全是最新的。恩智浦偶尔会发布更新的 BSP 来修复与 GPU 相关的问题。如果您使用的是旧版本的 Android 11 图像,那么这很可能就是罪魁祸首。 没有错误日志会让调试变得棘手,但你可以尝试在启动游戏时运行 adb logcat ——按 Unity 或应用程序包名称过滤,你可能会发现屏幕上没有显示的内容。希望对你有所帮助! 我是 Lucas 的所有者 =https://hillcrmapk.com/best-vehicle-in-hill-climb-racing/
記事全体を表示