关于S32 Design Stdio的功能安全评估 社区的朋友，大家好：        在项目的评估中遇到点问题，向大家求助：功能安全评估中有一项是工具置信度评估，需要评估软件开发过程中相关工具是否能够满足ASIL等级需求，S32DS作为免费自带的默认工具，如何保证能够满足软件开发的功能安全等级？请问有对应的证书或者认证吗？ Re: 关于S32 Design Stdio的功能安全评估 你好，迈克 我们也遇到了这个问题，能否与我分享相关文件。 电子邮件：[email protected] Re: 关于S32 Design Stdio的功能安全评估 你好、 我已通过私人信息向您发送了所需文件。 Re: 关于S32 Design Stdio的功能安全评估 你好 Mike， 如果可能的话，你能把工具链分类报告和功能安全手册发给我吗？谢谢；我的电子邮件地址：[email protected]； Re: 关于S32 Design Stdio的功能安全评估 你能给我发电子邮件以获取工具链分类报告和工具链功能安全手册吗？非常感谢。我的电子邮件是 jiandong.chao @d aisch.com Re: 关于S32 Design Stdio的功能安全评估 您好，迈克， 请将 TCR 和 TSM 文件发送至[email protected]。 谢谢！ 守冰 Re: 关于S32 Design Stdio的功能安全评估 您能给我发电子邮件吗？非常感谢。我的电子邮件是 [email protected] Re: 关于S32 Design Stdio的功能安全评估 Hi Mike, 如果可以，可以发一份给我吗？目前也遇到了关于S32 DS的功能安全评估的问题，谢谢！ Re: 关于S32 Design Stdio的功能安全评估 你好，Derrick， 目前我们只愿意提供 TCR 和 TSM 文件。 致以最诚挚的问候， Mike Re: 关于S32 Design Stdio的功能安全评估 嗨，德里克、 我需要向我的文件来源核实一下。我目前无法获得您所要求的文件。 顺祝商祺！ 米克 Re: 关于S32 Design Stdio的功能安全评估 嗨，迈克： ？我不太明白。您能说得更具体些吗？ 谢谢！ BR Derrick Re: 关于S32 Design Stdio的功能安全评估 检查这个。 Re: 关于S32 Design Stdio的功能安全评估 嗨，迈克： 能否将 TCQR 文件和其他文件发给我？ 非常感谢！ BR！ 德里克 Re: 关于S32 Design Stdio的功能安全评估 我也需要这个文件，请帮忙转我一份，谢谢 [email protected] Re: 关于S32 Design Stdio的功能安全评估 嗨，德里克、 我已经把文件发给你了。 顺祝商祺！ Mike Re: 关于S32 Design Stdio的功能安全评估 嗨，迈克， ，如果可能的话，请发给我。谢谢 BR! Derrick Re: 关于S32 Design Stdio的功能安全评估 你好，德里克、 S32DS 或恩智浦GCC编译器没有经过功能安全认证的版本。如果您感兴趣，我们有工具链分类报告和工具链功能安全手册。 顺祝商祺！ Mike Re: 关于S32 Design Stdio的功能安全评估 您好，迈克， 谢谢你的更新。我们在功能安全项目中也有同样的担忧，需要对S32DS 3.5进行工具评估。请提供相应的工具链分类报告和工具链功能安全手册？它们将对我们完成 S32DS 工具评估非常有帮助。 请将文件发送到我的邮箱： [email protected] 。 此致敬礼，李

MPXV7002DPはLPGおよびプロパンに対応しています。 こんにちは、 私は大学4年生です。現在、家庭用LPG配管の圧力差を測定するプロジェクトに取り組んでいます。配管内の通常の圧力は約2.30kPaから3.60kPaです。データシートを確認しましたが、LPGとの互換性については明確な記載がありませんでした。もし過去にこれを試した方や技術関係者がいれば教えていただけると助かります。 ありがとう 。 Re: MPXV7002DP compatibility with LPG and Propane こんにちは、 2026年2月2日現在、NXP MEMSセンサ製品はSTMicroelectronicsに移管されました。詳細についてはSTMicroelectronicsまでサポートまでお問い合わせください。

JCOP4 P71 — AES-GCM 和 AES-CCM 返回 NO_SUCH_ALGORITHM 我正在使用 NXP JCOP4 P71 卡，并试图了解为什么 AES-GCM 和 AES-CCM 似乎都不可用。 卡片详情： JCOP 4 P71 JCOP 版本：4.7 R1.01.4 平台 ID：J3R3510236310400 ATR：3BFA180000910131FE454A33523331302D333535FF JCOP 工具 6.15.0.11 Java Card Classic 3.0.5 其他加密功能，如 AES-128 ECB、SHA-256、RSA 和安全随机数生成，均能正常工作。 然而： * AES-GCM 返回 CryptoException.NO_SUCH_ALGORITHM * CryptoBaseX.ALG_AES_GCM 也返回 NO_SUCH_ALGORITHM * AEADCipher.ALG_AES_CCM 也返回 NO_SUCH_ALGORITHM 请问有人能澄清一下，GCM 和 CCM 是否应该支持此特定 JCOP4 P71 配置吗？ 尤其： 1. 平台 ID J3R3510236310400 是否支持 AES-GCM 和 AES-CCM？ 2. 这些算法是否依赖于特定的 OEF / 卡配置？ 3. 颁发后能否启用，还是需要不同的 JCOP4 卡配置？ 4. 是否有文档说明针对给定的 JCOP4 配置启用了哪些加密算法？ 我主要想确定这是否是此卡配置的预期行为，还是我的设置中遗漏了什么。 Smart Card Re: JCOP4 P71 — AES-GCM and AES-CCM return NO_SUCH_ALGORITHM 你好@sameer_chawla ， 答案如下： 1. 不，JCOP 4（平台 ID：J3R3510236310400）不支持 AES-GCM 和 AES-CCM。 2. 不，这些算法不受任何配置支持。 3. 不，它们无法自动启用，客户需要使用可用的 API 自行实现。 4. 是的，“um4695xx - 用户指南和管理员手册 JCOP4 P71”列出了可用的加密算法 还有另一份文档描述了我们 JCOP 平台上可用的加密算法： an7459xx - AN14334 - JCOP 4 P71、JCOP 4.5 P71 和 JCOP 5 P71 的比较 CIPHER_AES_CCM：JCOP 4 不支持，JCPO 4.5/5 支持。 CIPHER_AES_GCM：JCOP 4/4.5/5 不支持。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

A bug related to the incorrect generation of event callback function names for the top layer of the screen. The GUI Guider version I'm using is 2.0.0. When I'm working on Top...When adding events to a Layer, the event callback function names for the Top Layer in the generated gg_event_layer_top.c file are abnormal. Currently, a pair of parentheses is inserted in the middle of the event callback function name, like this: "static void lv_layer_top () _event_handler ( lv_event_t * e )". In fact, the same issue exists for the Bottom Layer, while Screens does not exhibit a similar problem. Hopefully, this bug can be fixed soon. Thank you! 回复： 关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug Hi @UENG , Thank you for your feedback. This issue has been fixed in version 2.0.1. Please download and install this version: GUI Guider Best Regards, Wenbin

如何直接联系AT&T客服人员？ 厌倦了自动语音菜单，只想和真人对话？AT&T客户支持团队（美国）

Coloured/Old Screen with IVI-SHELL IMX8QXP - Scarthgap  - L 6.6.52-weston 12-ivishell There is coloured/old screen is coming before updated screen. How to avoid/cleared/remove  it. weston.ini [core] #gbm-format=argb8888 idle-time=0 shell=ivi-shell.so # use-g2d=1 repaint-window=16 # pageflip-timeout=0 background-color=0x00000000 [libinput] touchscreen_calibrator=true [output] name=LVDS-1 mode=1280x720@60 [ivi-shell] ivi-shell-user-interface=weston-ivi-shell-user-interface ivi-input-module=ivi-input-controller.so ivi-id-agent-module=ivi-id-agent.so input-method=ivi-input-controller base-layer-id=1000 base-layer-id-offset=10000 workspace-background-layer-id=2000 workspace-layer-id=3000 application-layer-id=4000 transition-duration=0 [desktop-app-default] default-surface-id=2000000 default-surface-id-max=2001000 i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: Coloured/Old Screen with IVI-SHELL Hi, I tried the suggested one still same. The coloured/old screen still appearing. Is there any other suggestion or configuration required ? Thanks & regards, VKS Re: Coloured/Old Screen with IVI-SHELL Hello, Please try to change background color to 0x00000000 and uncomment gbm-format. You also can try to add a pre-start step to the Weston systemd service to clear the display before Weston initializes:  echo 1 > /sys/class/graphics/fbx/blank Best regards. Re: Coloured/Old Screen with IVI-SHELL Hello, Thank you for the update. This issue was reported before in a previous weston-imx-10.0.1 and solved with this patch: diff --git a/libweston/renderer-g2d/g2d-renderer.c b/libweston/renderer-g2d/g2d-renderer.c index 245a50de..d9df8b4e 100644 --- a/libweston/renderer-g2d/g2d-renderer.c +++ b/libweston/renderer-g2d/g2d-renderer.c @@ -2199,6 +2199,7 @@ drm_create_g2d_image(struct g2d_surfaceEx* g2dSurface, buffer->buf_vaddr = vaddr; buffer->buf_size = size; g2dSurface->base.planes[0] = buffer->buf_paddr; + memset(buffer->buf_vaddr, 0x00, size); g2dSurface->base.left = 0; g2dSurface->base.top = 0; g2dSurface->base.right = w; Add a memset when get the buffer, it can clear the buffer when weston start. In last weston-imx-15.0.1, this changes and a port is needed. Internal team confirmed that gl-renderer is not presenting the issue so, could you please help check if using gl-renderer helps you avoid the issue? (# use-g2d=1). Also, please share what you are seeing in your screen to understand better the behavior. Best regards. Re: Coloured/Old Screen with IVI-SHELL Hi, please find the images, Yes by using use-g2d=1 avoided coloured screen. But I seen the frame loss as well as no video is playing. And one more thing if I used use-g2d=1 , this is for software acceleration right ? . But we need hardware acceleration to avoid the frame loss. Please check and confirm. Thanks & regards, VKS

如何升级我与AT&T之间的问题？ 遇到AT&T的问题，一直没人能解决？AT&T 升级支持团队（美国）

imx93 – UUUシリアルダウンローダー起動中にUSBが切断される NXPチームの皆様へ 現在、MIMX9352AVTXMACプロセッサを使ってi.MX93のカスタムボードをデバッグしています。私たちのボードはLPDDR4で2ランクメモリ構成を採用しています。 UUU（Universal Update Utility）を使用して、オンボードのeMMCにプログラムを書き込みようとしています。ボードはシリアルダウンローダー／USBブートモードに設定されています。 i.MX93はUUUによって正しく検出されます。 uuu -lsusb NXP IMXチップ用uuu（Universal Update Utility） -- libuuu_1.5.243-10-g59c7638 既知のコネクテッドUSBデバイス Path Chip Pro vid pid bcdバージョンSerial_no ==================================================================== 3:1 MX93 SDPS: 0x1FC9 0x014E 0x0001 eMMCへの書き込みには、以下のコマンドを使用します。 sudo uuu -v -b emmc_all \ imx-boot-imx93evk-sd.bin-flash_singleboot \ image-imx93evk-20260905081644.rootfs.wic.zst UUUはi.MX93を検出し、SDPSブートコマンドを開始します。しかし、ブートローダーの転送を開始するとすぐに、USB接続が切断されてしまう。 関連するUUUログは以下のとおりです。 NXP IMXチップ用uuu（Universal Update Utility） -- libuuu_1.5.243-10-g59c7638 設定ファイルに含める: PctlチップビデオPID Bcdバージョンシリアル番号 ================================================== SDPS: MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS: MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS: MX8DXL 0x1fc9 0x0147 SDPS: MX28 0x15a2 0x004f SDPS: MX815 0x1fc9 0x013e SDPS: MX865 0x1fc9 0x0146 SDPS: MX8ULP 0x1fc9 0x014a SDPS: MX8ULP 0x1fc9 0x014b SDPS: MX93 0x1fc9 0x014e SDPS: MX91 0x1fc9 0x0159 SDPS: MX95 0x1fc9 0x015d SDPS: MX95 0x1fc9 0x015c SDPS: MX943 0x1fc9 0x0027 SDPS: MX952/IMX937 0x1fc9 0x0028 SDP: MX7D 0x15a2 0x0076 SDP: MX6Q 0x15a2 0x0054 SDP: MX6D 0x15a2 0x0061 SDP: MX6SL 0x15a2 0x0063 SDP: MX6SX 0x15a2 0x0071 SDP: MX6UL 0x15a2 0x007d SDP: MX6ULL 0x15a2 0x0080 SDP: MX6SLL 0x1fc9 0x0128 SDP: MX7ULP 0x1fc9 0x0126 SDP: MXRT106X 0x1fc9 0x0135 SDP: MX8MM 0x1fc9 0x0134 SDP: MX8MQ 0x1fc9 0x012b SDPU: SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV: SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV: SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU: SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU: SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV: SPL1 0x3016 0x1001 [0x0500..0x9998] FBK: 0x066f 0x9afe FBK: 0x066f 0x9bff FBK: 0x1fc9 0x0153 FB: 0x0525 0xa4a5 FB: 0x18d1 0x0d02 FB: 0x3016 0x0001 FB: 0x1fc9 0x0152 FB: 0x0483 0x0afb FB: 0x1d6b 0x0104 組み込みスクリプトを実行します: uuu_version 1.4.149 # @_flash.bin              |WICイメージから抽出できるブートローダー # @_image [_flash.bin]| wicイメージをemmcに書き込む。 # このコマンドは、i.MX6/7、i.MX8MM、i.MX8MQ の場合に実行されます SDP: boot -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 # このコマンドはROMがストリームモードをサポートするときに実行されます # i.MX8QXP、i.MX8QM SDPS: boot -scanterm -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 # これらのコマンドはSPLを使用する場合に実行され、SPLを使用しない場合はスキップされます # SDPU は非推奨になります。SDPUの代わりにSDPVを使用してください # ヤミン・アメックス SDPU: 遅延 1000 SDPU: write -f imx-boot-imx93evk-sd.bin-flash_singleboot -offset 0x57c00 SDPU: ジャンプ -scanlimited 0x800000 # } # これらのコマンドはSPLを使うときに実行され、SPLがなければスキップされます # もし(SPLがSDPVをサポートする場合) # { SDPV:ディレイ1000 SDPV: write -f imx-boot-imx93evk-sd.bin-flash_singleboot -skipspl -scanterm -scanlimited 0x800000 SDPV:ジャンプスキャン制限0x800000 # } FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all imx-boot-imx93evk-sd.bin-flash_singleboot FB: flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93evk-sd.bin-flash_singleboot FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: 完了 既知のUSBデバイスが表示されるまでお待ちください... 新しいUSBデバイスが3:1-6A440AB426084436に接続されました 3:1-6A440AB426084436>開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 3%3:1-6A440AB426084436>HID(W)エラー: LIBUSB_ERROR_NO_DEVICE (-4)(0.024秒) 起動コマンドを送信する際に、dmesgを使ってLinuxのUSBメッセージも監視しました。 i.MX93 USBデバイスが切断され、その後再び列挙されます。添付のdmesgのスクリーンショットを参照してください。 以下の質問について、ご助言いただければ幸いです。 UUUを使用している場合、i.MX93 SDPSブートローダーのハンドオフ中に、このUSB切断/再列挙は想定される動作ですか？ この特定の状況において、以下のエラーは何を示しているのでしょうか？HID(W)エラー: LIBUSB_ERROR_NO_DEVICE (-4) SDPSからSPL/U-Bootへのハンドオフ時に、カスタムボード上で確認すべき以下の信号に関する特別な要件はありますか？ POR_B RESET_b USB_VBUS USB_DP/DM プロセッサのパワーレール LPDDR4パワーレール システムクロック／基準クロック   i.MX93 MIMX9352AVTXMACの2ランクLPDDR4メモリ構成のリファレンス・デザインやソフトウェア/ブート構成の例を教えていただけますか?特に、2ランクメモリデザインにおける推奨されるLPDDR4デバイス構成、メモリ初期化/トレーニング構成、および対応するIMX_BOOT/SPL構成を確認したいと思います。 上記の問題についてご指導いただけるとありがたいです。2ランクLPDDR4構成に関する詳細、推奨構成、リファレンス・デザイン・コードのご提供をお願いいたします。 ありがとうございます。 アビシェク Re: imx93 – USB Disconnect During UUU Serial Downloader Boot こんにちは@pengyong_zhangさん 添付のLPDDR4回路図および構成.mexを参照してくださいご参考までに。 よろしくお願いいたします。 アビシェク Re: imx93 – USB Disconnect During UUU Serial Downloader Boot こんにちは、 @AbishekDevan さん。 1.これは想定される動作ではありません。 2．このエラーは、フラッシュ処理中にデバイスが切断されたために発生しました。お客様のDDR回路図ファイルと設定ページを共有してください。 B.R Re: imx93 – USB Disconnect During UUU Serial Downloader Boot こんにちは、 @AbishekDevan さん。 .mexをインポートできませんファイルが正常に処理されました。DDR設定ページのスクリーンショットを共有してください。 B.R

MPXV7002DP 与液化石油气和丙烷兼容 你好， 我是一名即将毕业的学生。我目前正在做一个项目，需要测量家用液化石油气管道中的压差。管路中的正常压力约为 2.30 kPa 至 3.60 kPa。我查阅了它的数据手册，但上面并没有明确说明它是否兼容液化石油气。所以，如果有人以前尝试过，或者有任何技术官员可以告诉我相关信息。 谢谢 。 Re: MPXV7002DP compatibility with LPG and Propane 你好， 截至 2026 年 2 月 2 日，NXP MEMS 传感器产品已转移至意法半导体。如需更多信息和支持，请联系意法半导体。

S32K118EVB2Q048：ADC读数与所选MCU供电电压不匹配 您好，NXP团队： 我正在使用 S32K118EVB2Q048 板（原理图 SCH-47530 Rev A1）测试 ADC。当输入电压超过约 3.3 V 时，我的读数就会出错。 设置： - MCU：S32K118（48-LQFP） - IDE：[S32 设计工作室版本] - 驱动程序：[RTD 版本 / SDK 版本 / 裸机版本] - ADC通道：[例如PTA7 – ADC0_SE3] 分辨率：12 位 - 输入：[外部直流电源/板载电位器] - 跳线：J10 = 2-3 (5V)、J107、J15 - 板供电方式：[USB / 12V] 问题： 我将 J10 设置为 2-3，这样 MCU 就可以在 5V 电压下运行。 - 输入 4.10 V：原始值 = 4095。以 5V 为参考电压，我预期读数约为 3358。 - 4V 至 5V 之间的任何输入：始终为 4095（满量程）。 - 当我使用 5V 电压进行计算时，随着输入电压的增加，误差也会增加。 问题： 在 SCH-47530 Rev A1 上，将 J10 设置为 2-3 是否足以使 VDDA 和 ADC 参考电压为 5V，还是我还需要更改其他任何东西（J15、J107、任何电阻器）？ 能否分享一个适用于此EVB的S32K118 ADC工作示例，并用5V基准电压进行测试？能否也提供不同分辨率下的计算范围？ Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage 你好 请问您使用的是哪个RTD/SDK版本？ 另外，我看到你正在使用 PTA7，但是你提到了 ADC_POT。由于 EVB 上未安装 R761，因此 ADC_POT 未连接： 我假设您是通过 J3.1 接头使用 PTA7。 请确认J10和J107都设置为 2-3，并尝试测量 VDD，以确保它确实设置为 5V。 我使用了RTD软件包中的Adc_Pdb_Ip_example_S32K118 ，并简单地修改了main函数，使其循环并启动软件转换： while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } 之后，我使用电源测量了 0 到 5V 之间的电压，可以看到正确的数值。 ADC0_SE2 @3.3V： ADC0_SE2 @5V： 最后，检查 ADC_SC2[REFSEL] 中 REFSEL 是否设置正确： 此致， 朱利安

LPC55S0x CANFD 能否支持 1Mbps（仲裁阶段）和 8Mbps（数据阶段）？ 您好，NXP， LPC55S0x能否在仲裁阶段支持1Mbps，在数据阶段支持8Mbps？ 我在LPC55S0x数据手册中找不到。 非常感谢。 LPC55xx Re: Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) 嗨，哈里， 知道了。 谢谢。 Re: Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) 嗨@jimmyli 是的——只要 MCAN 功能时钟为 96 MHz，并且外部 CAN-FD 收发器和物理网络支持 8 Mbit/s，LPC55S0x CAN-FD 控制器就可以配置为 1 Mbit/s 仲裁和 8 Mbit/s 数据。 之所以没有直接在数据手册中列出，是因为比特率是从 MCAN 时钟和 NBTP / DBTP 定时寄存器推导出来的，而不是指定为固定的最大值。CAN 时钟可以使用 main_clk，其中 CANCLKDIV = 0（分频至 1），LPC55S0x 的最大时钟频率为 96 MHz。 BR 哈里

AT&Tに関する問題をエスカレートするにはどうすればよいですか？ AT&Tの不具合で、解決策が見つからずたらい回しにされている状況に陥っていませんか？AT&T エスカレーションサポートチーム(米国)

imx93 – UUU 串行下载器启动期间 USB 断开连接 尊敬的恩智浦团队： 我们目前正在使用 MIMX9352AVTXMAC 处理器调试我们的 i.MX93 定制板。我们的主板采用双列LPDDR4内存配置。 我们正在尝试使用 UUU（通用更新实用程序）对板载 eMMC 进行编程。该板配置为串行下载器/USB启动模式。 UUU 已正确检测到 i.MX93： uuu -lsusb 适用于 NXP imx 芯片的 uuu（通用更新实用程序）-- libuuu_1.5.243-10-g59c7638 已连接的已知 USB 设备 路径芯片专业版视频 PID BCD版本 序列号 ==================================================================== 3:1 MX93 SDPS：0x1FC9 0x014E 0x0001 我们使用以下命令对 eMMC 进行编程： sudo uuu -v -b emmc_all \ imx-boot-imx93evk-sd.bin-flash_singleboot \ image-imx93evk-20260905081644.rootfs.wic.zst UUU 检测到 i.MX93 并启动 SDPS 启动命令。然而，启动引导加载程序传输后，USB 连接立即断开。 相关的UUU日志如下： 适用于 NXP imx 芯片的 uuu（通用更新实用程序）-- libuuu_1.5.243-10-g59c7638 内置配置： PCTL芯片VID PID BCD版本 序列号 ================================================== SDPS：MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS：MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS：MX8DXL 0x1fc9 0x0147 SDPS：MX28 0x15a2 0x004f SDPS：MX815 0x1fc9 0x013e SDPS：MX865 0x1fc9 0x0146 SDPS：MX8ULP 0x1fc9 0x014a SDPS：MX8ULP 0x1fc9 0x014b SDPS：MX93 0x1fc9 0x014e SDPS：MX91 0x1fc9 0x0159 SDPS：MX95 0x1fc9 0x015d SDPS：MX95 0x1fc9 0x015c SDPS：MX943 0x1fc9 0x0027 SDPS：MX952/IMX937 0x1fc9 0x0028 SDP：MX7D 0x15a2 0x0076 SDP：MX6Q 0x15a2 0x0054 SDP：MX6D 0x15a2 0x0061 SDP：MX6SL 0x15a2 0x0063 SDP：MX6SX 0x15a2 0x0071 SDP：MX6UL 0x15a2 0x007d SDP：MX6ULL 0x15a2 0x0080 SDP：MX6SLL 0x1fc9 0x0128 SDP：MX7ULP 0x1fc9 0x0126 SDP：MXRT106X 0x1fc9 0x0135 SDP：MX8MM 0x1fc9 0x0134 SDP：MX8MQ 0x1fc9 0x012b SDPU：SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV：SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV：SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU：SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU：SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV：SPL1 0x3016 0x1001 [0x0500..0x9998] FBK：0x066f 0x9afe FBK：0x066f 0x9bff FBK：0x1fc9 0x0153 FB：0x0525 0xa4a5 FB：0x18d1 0x0d02 FB：0x3016 0x0001 FB：0x1fc9 0x0152 FB：0x0483 0x0afb FB：0x1d6b 0x0104 运行内置脚本： uuu_version 1.4.149 # @_flash.bin| 引导加载程序，可以从 WIC 镜像中提取 # @_image [_flash.bin]| 将 WIC 镜像刻录到 EMMC。 # 此命令将在 i.MX6/7、i.MX8MM、i.MX8MQ 运行时运行 SDP：boot -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 # 当 ROM 支持流模式时，将运行此命令 # i.MX8QXP，i.MX8QM SDPS：boot -scanterm -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # SDPU 将被弃用。请使用 SDPV 代替 SDPU # { SDPU：延迟 1000 SDPU：写入 -f imx-boot-imx93evk-sd.bin-flash_singleboot -offset 0x57c00 SDPU：跳转 -scanlimited 0x800000 # } # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # 如果（SPL 支持 SDPV） # { SDPV：延迟 1000 SDPV：写入 -f imx-boot-imx93evk-sd.bin-flash_singleboot -skipspl -scanterm -scanlimited 0x800000 SDPV：跳转 -scanlimited 0x800000 # } FB：ucmd setenv fastboot_dev mmc FB：ucmd setenv mmcdev ${emmc_dev} FB：ucmd mmc dev ${emmc_dev} FB：flash -raw2sparse all imx-boot-imx93evk-sd.bin-flash_singleboot FB：flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93evk-sd.bin-flash_singleboot FB: ucmd 如果环境变量 emmc_ack 存在；则；否则设置环境变量 emmc_ack 为 0；结束； FB：ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB：完成 等待已知 USB 设备出现…… 新的 USB 设备已连接到 3:1-6A440AB426084436 3:1-6A440AB426084436>启动命令：SDPS：启动 -scanterm -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 3%3:1-6A440AB426084436>失败 HID(W): LIBUSB_ERROR_NO_DEVICE (-4)(0.024秒) 在发送启动命令的同时，我们还使用 dmesg 监测了 Linux USB 消息。 i.MX93 USB 设备已断开连接，然后再次枚举，请参考附件中的 dmesg 屏幕截图。 我们希望您能就以下问题提供指导： 在使用 UUU 时，i.MX93 SDPS 引导加载程序切换过程中是否预期会出现 USB 断开/重新枚举的情况？ 在这种特定情况下，以下错误表明了什么？HID(W) 失败：LIBUSB_ERROR_NO_DEVICE (-4) 在 SDPS 到 SPL/U-Boot 的切换过程中，以下信号是否有任何特殊要求，我们需要在定制板上进行验证？ POR_B RESET_b USB_VBUS USB_DP/DM 处理器电源轨 LPDDR4 电源轨 系统/参考时钟   能否提供采用双列 LPDDR4 内存配置的 i.MX93 MIMX9352AVTXMAC 的参考设计或软件/启动配置示例？具体来说，我们希望确认双列内存设计中推荐的 LPDDR4 设备配置、内存初始化/训练配置以及相应的 IMX_BOOT/SPL 配置。 我们希望您能就上述问题提供指导，并请您提供双列 LPDDR4 配置的相关细节、推荐配置和参考设计/代码。 谢谢 & 此致敬礼， 阿比舍克 Re: imx93 – USB Disconnect During UUU Serial Downloader Boot 嗨@pengyong_zhang ， 请参考附件中的 LPDDR4 原理图和配置 .mex 文件。供您参考。 此致， 阿比舍克 Re: imx93 – USB Disconnect During UUU Serial Downloader Boot 嗨@AbishekDevan 1.这并非预期行为。 2. 此错误是由于设备在刷机过程中断开连接造成的。请分享客户的DDR原理图文件和配置页面。 B.R Re: imx93 – USB Disconnect During UUU Serial Downloader Boot 嗨@AbishekDevan 我无法导入您的 .mex 文件。文件已成功提交。请分享一下您的DDR配置页面截图。 B.R

KE18F512VLH16 ECC RAM 单比特纠错 我有一个与@sean_dvorscak前几天的帖子（ KE1 ECC RAM 单比特纠错）相关的后续问题。 @Celeste_Liu回复道： 如果要实现可选的清理功能，请根据实际访问大小或清理粒度来对齐访问，而不是盲目地依赖原始的 MCM_LMFAR 值。此外，除非您已正确对齐地址并确认访问大小有效，否则请勿使用固定的 4 字节访问。 MCM_LMFATR[PEFSIZE] 能否用于确定访问大小？如果可以，能否将其与 MCM_LMFAR 结合使用，以实现读取-正确-写回操作？例如，如果 MCM_LMFATR[PEFSIZE] 为 3'b000，表示 8 位访问，我能否从 MCM_LMFAR 指示的地址执行 8 位读取，然后对同一地址执行 8 位写入以纠正错误？同样地，如果 MCM_LMFATR[PEFSIZE] 为 3'b010，表示 32 位访问，我是否可以对 MCM_LMFAR 指示的地址执行 32 位写入，而无需担心对齐问题？ Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 我已看过你的帖子。我需要一些时间来调查这个问题，一旦有更多信息，我会尽快回复您。 BR 塞莱斯特 Re: KE18F512VLH16 ECC RAM Single Bit Correction 嗨@Celeste_Liu - P7 是最终应用程序的名称。 Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 关于您的问题，我需要将其上报给内部团队进行进一步调查。根据我们的流程，请提供最终应用程序名称。 谢谢您的合作。 BR 塞莱斯特 Re: KE18F512VLH16 ECC RAM Single Bit Correction @Celeste_Liu你好，请问这件事有任何进展吗？ Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 抱歉，我还没有收到内部回复。 我会再次跟进此事，并将其作为我的首要任务。一旦收到回复，我会立即通知你。 BR 塞莱斯特 Re: KE18F512VLH16 ECC RAM Single Bit Correction 感谢@Celeste_Liu的回复，但这并没有回答我关于MCM_LMFATR[PEFSIZE] 的问题： “ MCM_LMFATR[PEFSIZE] 能否用于确定访问大小？如果可以，能否将其与 MCM_LMFAR 结合使用，实现读取-纠错-写回操作？例如，如果 MCM_LMFATR[PEFSIZE] 为 3'b000，表示 8 位访问，我能否先从 MCM_LMFAR 指示的地址读取 8 位数据，然后再向同一地址写入 8 位数据以纠正错误？类似地，如果 MCM_LMFATR[PEFSIZE] 为 3'b010，表示 32 位访问，我能否直接向 MCM_LMFAR 指示的地址写入 32 位数据而无需考虑对齐问题？” Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 感谢您的耐心等待。我收到了内部回复。 ECC“纠错”是指将纠正后的数据返回给CPU，而不是修复存储在SRAM中的底层位。自动修复需要单独的擦除/回写机制。 使用软件清理的推荐流程： ECC在读取时纠正数据。 引发单比特错误中断/状态。请参阅 RM 6.3.1.1确定中断源。MCM_LMPECR [ER1BR] =1 软件读取故障地址。MCM_LMPEIR [PEELOC] = 5'h08 - 来自 SRAM_L 的 1 位可纠正 ECC 事件，MCM_LMFAR 指示故障地址。 软件会将更正后的值写回原地址。 生成并存储新的 ECC 综合征。 BR 塞莱斯特

Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) Hi NXP,       Can LPC55S0x support 1Mbps in arbitration stage and 8Mbps in data stage ?       I can't find in LPC55S0x datasheet.      Thanks very much. LPC55xx Re: Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) Hi Harry,       Got it.       Thanks. Re: Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) Hi @jimmyli  Yes— the LPC55S0x CAN-FD controller can be configured for 1 Mbit/s arbitration and 8 Mbit/s data , provided the MCAN functional clock is 96 MHz and the external CAN-FD transceiver and physical network support 8 Mbit/s. The reason this is not listed directly in the datasheet is that the bit rates are derived from the MCAN clock and the NBTP / DBTP timing registers rather than specified as a fixed maximum. The CAN clock can use main_clk with CANCLKDIV = 0 (divide-by-1), and the LPC55S0x maximum clock frequency is 96 MHz. BR Harry

AT&Tの担当者と直接話すにはどうすればよいですか？ 自動音声メニューにうんざりして、実際に人と話したいと思いませんか？AT&T カスタマーサポートチーム (米国)

运行 OpenGL 程序时出现多次 GPU 崩溃/无效输出 您好， 三年多来，我们一直在销售基于 i.MX6QuadPlus 的设备，该设备基于 Yocto hardknott 构建，并搭载了基于 Weston 的 Qt 6.3.2。随着产品的发展，我们开始收到越来越多的用户崩溃报告，但我们在自己的代码或 Qt 中都找不到原因。我们已经修复了一些问题——通过重新调整 DDR 时序、禁用某些视图中的阴影、增加一些内部缓冲大小以及使用 GPU_VIV_EXT_RESOLVE=0 运行应用程序——但我们仍然会收到报告，其中很大一部分与 GPU 相关，并在日志中显示如下： 内核：*** GPU DRV 配置 *** 内核：Galcore 版本 6.4.3.336687 内核：Galcore 选项： ... 内核: [galcore]: 停止驱动程序以保持场景。 这是驱动程序自身的挂起报告——监测计时器未见任何进展，gckKERNEL_Recovery 转储 GPU 状态，并且由于 recovery=0，驱动程序停止服务而不是重置核心（recovery=1 对我们来说不是一个选项，因为需要重新启动每个 GUI 应用程序）。屏幕彻底冻结，即使使用 SIGKILL 也无法杀死 Weston，唯一的解决办法是断电——这对我们的客户来说非常糟糕。 由于我们已经在 Qt 和应用程序层面尝试了很多方法，但都只得到了变通方案，所以我决定停止测试高级功能，而是直接测试 OpenGL ES 入口点——如果它们运行正常，那就是我们的问题；如果它们运行不正常，那就是驱动程序/硬件的问题（至少是部分问题）。 我使用 VK-GL-CTS（ https://github.com/KhronosGroup/VK-GL-CTS ）实现了这一点。首先移植到 Rust 以便于交叉编译（仍在进行中，因此目前只能检查大约一半的相关情况）。案例名称与上游 deqp-gles2/gles3/gles31 相同，并且在 Mesa llvmpipe 和运行 Ubuntu 24.04 的普通笔记本电脑上，所有测试均通过，并且也安装了 mesa 驱动程序，因此板上的失败说明板存在问题。我利用周末时间在硬件上运行了它，并在人工智能的帮助下，找到了 14 个不同的缺陷并将其最小化，每个缺陷现在都可以独立复现：一个没有任何依赖项的纯 Rust 项目，仅使用 cargo build 构建，GLSL 代码放在单独的文件中。 （只需运行- 在本地运行，您可以提取仅 arm部分，只需构建步骤即可收集二进制文件（您需要先安装cargo install --locked cargo-zigbuild ）） 6.4.11.p4 版本（我们能为该部件构建的最新驱动程序）仍然存在问题： 0001 GPU 锁死 - synchronization.inter_invocation.ssbo_atomic_read_write，独自一人，站在一块刚启动的板上。只有重启才能清除它，而且该进程无法终止，因此重启本身需要 8-10 分钟。 0002 GPU 锁定 - synchronization.inter_invocation.ssbo_atomic_overwrite，单独发生。 0003 GPU 锁死 - 二十个 synchronization.inter_invocation.* 中的十个个别案例单独存在，其他十个案例则不存在，因此这是一个边界，而不是“计算出错”。所有原子 ssbo/图像变体。所有二十台设备都进行了十次运行，每次运行都是从它自己的重启开始。 0010 链路故障 - 7 个 ubo 案例，其中两个阶段读取了同一个 std140 块的 47 个成员。单独一个阶段可以连接，但两个阶段一起连接则不行，glGetProgramInfoLog 为空，并且没有任何东西接近驱动程序本身报告的限制（每个阶段 3 个块 vs 16 个，704 字节 vs 65536）。至少需要 47 次阅读，46 个链接。 0011 结果错误 - shaders.invariance.highp.loop_*:两个着色器使用相同的表达式计算不变的 gl_Position，结果相差几个像素的深度。 0013 错误状态枚举 - fbo.completeness.size.distinct：请求的上下文是 ES 2.0，但报告的是 ES 3.1，然后根据 ES 2.0 规则回答完整性问题，并返回一个 ES 3.x 未定义的枚举。 已在 6.4.3.p2 版本中修复-> 6.4.11.p4 跳转： 0004 GPU 死锁 - image_load_store.cube.qualifiers.*_r32f（旁边的 r32ui/r32i 型号都没问题） 0006 GPU 锁死 - image_load_store.* 每当图像分层时都会发生，21 层中有 8 层发生，而 2D 图像上 7 层中没有发生，间歇性发生 0005 客户端冻结 - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange 永远不会返回 0014 客户端冻结 - 同样，通过 upload_buffer.empty_command 命令实现。一旦调度任务已经完成映射 0007 结果错误 - 计算着色器中包含十八个 && 的链，并且声明了一个原子计数器，当每个项都为真时，结果为假（2007 个 ssbo.layout 案例中的 44 个） 0008 编译器 - 保留字表适用于错误的语言版本，正反两面都是如此。 0009 结果错误 - 对于两个相等的向量，vec3 == vec3 为 false，这是通过 inout 参数返回的结构体成员的结果。 0012 编译器 - mediump vec2(1.0,1.0) 可以编译，其中 ESSL 1.00 语法中没有精度限定符的位置。 两次测试均在同一块主板上进行：i.MX6QP 硅 rev 1.0，2 GiB DDR，LVDS 1280x1024@60，Weston on fbdev with use-g2d=1，GL_RENDERER "Vivante GC2000+"。 旧版本：hardknott，BSP imx-5.10.52-2.1.0，内核版本 5.10.52galcore 6.4.3.p2.336687，imx-gpu-viv 1:6.4.3.p2.2-aarch32，Weston 9.0.0.imx，Qt 6.3.2 新增：wrynose，BSP imx-6.18.20-2.0.0，内核 6.18.20，galcore 6.4.11.p4.1190909，imx-gpu-viv 1:6.4.11.p4.6-aarch32Weston 10.0.5.imx，Qt 6.11.0 CONFIG_MXC_GPU_VIV=y，recovery=0 和 stuckDump=0 在两者上；超时时间为 20000 -> 30000 毫秒，并且 6.4.11.p4 添加了 softReset=1。 所以版本升级有所帮助，但一些问题仍然存在。由于 i.MX6 的供货情况，我们将很快迁移到 i.MX8，但我们现有的用户群无论如何都会继续使用 i.MX6 硬件，因此我们希望这些问题在未来能够得到解决。 这些问题有没有可能在新版本的驱动程序中得到修复，即使这意味着我们需要升级 Yocto 版本？ 我担心 i.MX8 也可能存在某种程度的此类问题，那么是否已经对 Vulkan/OpenGL CTS 进行过测试，现在是否正在进行测试，或者是否有计划进行测试？因为如果不通过那项测试（再加上一些模糊测试，例如随机执行cts函数），我认为我们遇到的随机崩溃问题无法在驱动程序之上的层级中得到修复。 Re: Several gpu crashes/invalid output, when running opengl es cts 你好， i.MX 6/7 的最新公开发布驱动程序是 imx-gpu-viv 6.4.11.p4.6 ，随附 wrynose 电路板支持包 (imx-6.18.20-2.0.0)。发行说明将此次升级描述为对 i.MX 6/7/8 系列进行了“错误修复和性能优化”，这与您的观察结果相符，即 .p2 和 .p4 之间解决了 14 个缺陷中的 8 个。是的，这确实正在发生——但各个平台都有一些重要的限制条件。对于配备 Vivante (VSI) GPU 的 i.MX8，CTS 正在运行。作为每个版本候选周期的一部分，内部 Linux Factory 测试流程都会针对 i.MX8 板运行 opengl-es-cts 和 vulkan-cts 软件包。在 Linux Factory Jira 项目 CTS 中跟踪在 i.MX8M Nano、i.MX95 上发现的缺陷。这意味着 i.MX8M Plus、i.MX8QuadMax 等产品中的 Vivante GC7000 系列 GPU 在每次正式版本前都会经过系统的符合性测试。 适用于配备 Mali / OSS Mesa 的 i.MX9 版本说明明确指出，对于采用 Mesa OSS GPU 堆栈的 i.MX 95/952：“OpenGL ES11、Vulkan 1.4.5 和 OpenCL 3.0 的基本功能可以正常工作，但一致性测试未通过。” 这i.MX9 上的 Mali DDK 默认路径通过了 CTS 测试，但开源 Panfrost/PanVK 路径仍在努力使其符合标准。 特别是对于 i.MX6 (GC2000+) 而言，CTS 的覆盖范围非常有限。 在当前的 Linux Factory 流水线中，没有发现针对 GC2000+ 的系统性 deqp/CTS 运行的内部证据。GC2000+ 仅支持 OpenGL ES 3.0（不支持 3.1/3.2）。测试基础设施似乎针对的是较新的 i.MX8/9 板。您与 VK-GL-CTS 的合作是对该特定 IP 进行的最彻底的一致性级别测试，在任何内部渠道中都是可见的。   总之：虽然不能保证未来会发布 i.MX6 驱动程序补丁，但通过您开放的支持帖子提供独立的重现步骤才是正确的做法。对于您的 i.MX8 迁移，Vivante GC7000 系列的兼容性情况比 GC2000+ 要好得多，并且系统性的 CTS 测试是发布过程的一部分——尽管即便如此， galcore 6.4.11.p4 中的活跃驱动程序错误仍然不断被发现和提交。   此致 Re: Several gpu crashes/invalid output, when running opengl es cts 我没看到附件，看来是我忘记添加了，所以我再添加一次。

关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug 我使用的GUI Guider版本是2.0.0。当我为Top Layer添加事件时，生成的gg_event_layer_top.c中关于Top Layer的事件回调函数名会异常，目前的情况是，事件回调函数名的中间会被插入一对括号，就像这样“ static void lv_layer_top () _event_handler ( lv_event_t * e ）”。事实上，对于Bottom Layer也存在相同的问题，而Screens则未出现类似的问题。希望能尽快修复bug。谢谢！ 回复： 关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug Hi @UENG , 感谢您的反馈，该问题已经在V2.0.1中修复，请下载安装该版本：GUI Guider Best Regards, Wenbin

OpenGL es ctsを実行しているときに、いくつかのGPUがクラッシュしたり無効な出力が出たりします こんにちは、 3年以上にわたり、私たちはi.MX6QuadPlusでデバイスを出荷してきました。これはYocto hardknott上で構築され、WestonのQt 6.3.2で構築されています。製品が成長するにつれて、ユーザーからクラッシュ報告が増え、自分たちのコードやQtの中に原因が見つかりませんでした。一部は修正できました。DDRのタイミングを調整したり、特定のビューでシャドウを無効にしたり、内部バッファのサイズを増やしたり、アプリをGPU_VIV_EXT_RESOLVE=0で動かしたりしましたが、それでもレポートは届き、その多くはGPU関連でログに次のように表示されます。 カーネル: *** GPU DRV 設定 *** カーネル:Galcore バージョン 6.4.3.336687 カーネル:Galcoreオプション: ... カーネル:[galcore]: シーンを保つためにドライバを止めてください。 これはドライバ自身のハングレポートで、モニタータイマーは進行状況を認識せず、GPUの状態をダンプgckKERNEL_Recovery、recovery=0なのでドライバはコアをリセットせずサービスを停止します(recovery=1は私たちには選択肢にありません。なぜなら、すべてのGUIアプリケーションを再起動する必要があるからです)。画面は完全にフリーズし、ウェストンはSIGKILLを使っても倒せないことが多く、唯一の脱出方法は停電で、これはお客様にとって非常に悪いことです。 Qtやアプリケーションレベルで多くのことを試しましたが、回避策しか得られなかったため、高レベルの機能テストをやめ、OpenGL ESのエントリポイントを直接テストすることにしました。正常に動作すれば問題は私たちの責任、そうでなければドライバやハードウェアの故障(少なくとも部分的)です。 私はVK-GL-CTS（ https://github.com/KhronosGroup/VK-GL-CTS ）を使ってそれをやりました。クロスコンパイルを簡単にするために最初はRustに移植されました(まだ進行中で、関連するケースの約半分しか確認できませんでした)。ケース名は上流のdeqp-gles2/gles3/gles31と同じで、Mesa llvmpipeやUbuntu 24.04のカジュアルノートPC(Mesaドライバー付き)でもすべてパスされます。つまり、ボードの故障はボード自体の問題です。週末にハードウェア上で実行したところ、AIの助けを借りて14個の異なる欠陥を発見し、最小限に抑えることができました。それぞれが独立した再現可能なコードになっています。具体的には、依存関係のないシンプルなRustプロジェクト、cargoビルドのみ、そしてGLSLを独自のファイルに記述したものです。 (JUst Run - ローカルで実行、 Armパーツだけ を抽出して、ビルドステップのみでバイナリを集められます(最初の カーゴインストールが必要で、ロックされたカーゴ・ジグビルド) この部分のために構築可能な最新ドライバー、6.4.11.p4で依然として問題が残っています: 0001 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_read_write,一人きり、新しく履き替えたばかりのボードの上で。再起動しないとクリアできませんし、プロセス自体は壊せないので8〜10分かかります。 0002 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_overwrite、単体で。 0003 GPUのロックアップ - 20 synchronization.inter_invocation中10件。*ケースは単独で起こるが、他の10個はそうではないため、これは境界であり「計算が壊れている」とは言えない。すべての原子SSBO/イメージのバリアント。20人全員がそれぞれ10回のレースを制覇し、すべてのレースはリブート版から始まった。 0010リンク障害 - 同じstd140ブロックの47個のメンバーが両段階で読み取れた7件のUBOケース。どちらのステージだけでもリンクしますが、一緒にはリンクしません。glGetProgramInfoLogは空で、ドライバー自体が報告する制限(ステージあたり3ブロック対16ブロック、704バイト対65536バイト)はほとんどありません。最低でも47回の閲覧と46のリンクが必要です。 0011 結果が間違っています - shaders.invariance.highp.loop_*:同じ式から不変なgl_Positionを計算する2つのシェーダーが、深度に関して数ピクセルの差を生じます。 0013 ステータス列挙型が間違っています - fbo.completeness.size.distinct: ES 2.0 として要求されたコンテキストが ES 3.1 を報告し、その後 ES 2.0 ルールで完全性に応答し、ES 3.x で定義されていない列挙型を返します。 6.4.3.p2で修正済み-> 6.4.11.p4 ジャンプ: 0004 GPUロックアップ - image_load_store.cube.qualifiers.*_r32f（隣にあったr32ui/r32iは問題なかった） 0006 GPUのロックアップ - image_load_store.* 画像がレイヤー化されるたびに、21枚中8枚、2Dでは7枚中0枚、断続的です 0005 クライアントフリーズ - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange は決して戻りません 0014 クライアントフリーズ - upload_buffer.empty_command 経由、同じ一度、配車がすでにマッピングされている場合 0007 誤った結果 - 18 &&の連鎖で、原子カウンタも宣言される場合、すべての項が真である場合にfalseになります(2007年のssbo.layoutケース中44件) 0008 コンパイラ - 保留ワードテーブルは間違った言語バージョン用、両方向に適用されます 0009 誤った結果 - 入力パラメータを介して返される構造体メンバーに対して、2 つの等しいベクトルに対して vec3 == vec3 が false になります 0012 コンパイラ - mediump vec2(1.0,1.0) コンパイルは成功するが、ESSL 1.00 文法には精度修飾子を入れる場所がない。 両方のテストは同じボードで行いました：i.MX6QPシリコンリビジョン1.0、2 GiB DDR、LVDS 1280x1024@60、fbdev上のWeston、use-g2d=1、GL_RENDERER "Vivante GC2000+"。 古い: hardknott、BSP imx-5.10.52-2.1.0、カーネル 5.10.52、Galcore 6.4.3.p2.336687、IMX-GPU-VIV 1:6.4.3.p2.2-aarch32,Weston 9.0.0.imx、Qt 6.3.2 new: wrynose、BSP imx-6.18.20-2.0.0、kernel 6.18.20、galcore 6.4.11.p4.1190909、imx-gpu-viv 1:6.4.11.p4.6-aarch32,Weston 10.0.5.imx、Qt 6.11.0 CONFIG_MXC_GPU_VIV=y、recovery=0、stuckDump=0 の両方でタイムアウトが発生し、20000 -> 30000 ms となり、6.4.11.p4 で softReset=1 が追加されました。 バージョンアップは助けになりますが、いくつかの問題は残っています。i.MX6の入手可能性のため、近いうちにi.MX8に移行する予定ですが、既存の基盤はいずれにせよi.MX6のハードウェアを保持しているので、将来的にこうした問題が解決されるのを見たいです たとえYocto版をやめざるを得なくても、新しいドライバーでこれらの問題が修正される可能性はありますか? この問題はi.MX8にもある程度存在しているのではないかと懸念していますが、Vulkan/OpenGL CTSでテストは行われていますか?現在行われているのか、それとも計画されているのでしょうか?それを通さなければ(さらにcts関数のランダム実行などのファズ処理も)、ドライバーの上層でランダムクラッシュは修正できないと思います Re: Several gpu crashes/invalid output, when running opengl es cts こんにちは、 i.MX 6/7の最新公開ドライバーは imx-gpu-viv 6.4.11.p4.6 で、wrynose BSP(imx-6.18.20-2.0.0)が付属しています。リリースノートでは、そのジャンプが i.MX 6/7/8ラインの「バグ修正、パフォーマンス最適化」をもたらしたと説明されており、これはあなたの観察と一致しています。 .p2 と .p4 の間に14の欠陥のうち8つが解決されたという点です。そして確かに、それは行われていますが、プラットフォームごとに重要な条件があります。Vivante(VSI)GPU搭載のi.MX8では、CTSが動作しています。Linux Factory内部のテストパイプラインでは、各リリース候補サイクルの一環として、i.MX8ボードに対して opengl-es-cts および vulkan-cts パッケージの両方を実行させます。発見された欠陥は、Linux Factory JiraプロジェクトCTSのi.MX8M Nano、i.MX95上で追跡されています。これは、i.MX8M Plus、i.MX8QuadMaxなどに搭載されているVivante GC7000シリーズGPUは、各GAリリース前に体系的な適合性テストを受けていることを意味します。 i.MX9（Mali / OSS Mesa搭載）向け リリースノートには、Mesa OSS GPUスタック搭載 i.MX 95/952について明記されています:「OpenGL ES11、Vulkan 1.4.5、OpenCL 3.0の基本機能は動作していますが、適合性テストは合格していません。」そのi.MX9上のMali DDKのデフォルトパスはCTSに合格していますが、オープンソースのPanfrost/PanVKパスはまだ適合化の作業中です。 i.MX6 (GC2000+) に関しては、CTS のカバー範囲は最小限です。 現在のLinux Factoryパイプラインにおいて、GC2000+に対して体系的なdeqp/CTS実行が行われているという内部証拠は見つかりませんでした。GC2000+はOpenGL ES 3.0のみをサポートしており(3.1/3.2はサポートしていません)、テストインフラストラクチャは新しいi.MX8/9ボードをターゲットにしているようです。VK-GL-CTSでの作業は、この特定のIPに対する内部チャネルで見られる最も徹底した適合レベルのテストです。   結論として、FUTURE i.MX6ドライバーパッチが保証されているわけではありませんが、オープンサポートThreadを通じてスタンドアロンのリプロダクションを提供するのが正しい方法です。i.MX8移行に関しては、Vivante GC7000シリーズの適合状況がGC2000+よりも大幅に優れており、体系的なCTSテストもリリースプロセスの一部となっていますが、それでもなお galcore 6.4.11.p4 のドライバーバグは依然として発見・報告されています。   よろしくお願いします。 Re: Several gpu crashes/invalid output, when running opengl es cts 添付ファイルが見当たらず、追加を忘れたようだったので、もう一度追加しました

KE18F512VLH16 ECC RAM シングルビット訂正 先日@sean_dvorscakさんが投稿された記事（ KE1 ECC RAM シングルビット訂正）に関連して、追加の質問があります。 @Celeste_Liuは答えた。 ->> オプションのスクラブを実装する場合は、アクセスを実際のアクセスサイズやスクラブの粒度に基づいてアライメントし、生の MCM_LMFAR 値に盲目的に合わせないでください。また、アドレスを適切にアラインメントし、アクセスサイズが有効であることを確認しない限り、固定4バイトのアクセスは使わないでください。 MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを判定できますか?もしそうなら、これをMCM_LMFARと組み合わせて読み取り・正解・書き込み操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、同じアドレスに8ビットの書き込みをして誤りを訂正することは可能でしょうか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビット書き込みを行うことはできますか? Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 あなたの投稿を拝見しました。この件について少し調査させてください。詳しい情報が分かり次第、改めてご連絡いたします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは@Celeste_Liu - P7は最終アプリケーションの名前です。 Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 ご質問につきましては、社内の担当チームに調査を依頼する必要があります。当社の手続きに従い、 最終的な申請 名を記載してください。 ご協力ありがとうございました。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @Celeste_Liu さん、この件について何か進展はありますか？ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 申し訳ありませんが、まだ社内からの返答がありません。 再度連絡を取り、これを最優先事項として取り組みます。何か返事が来たらすぐにお知らせします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @rseigle77 さん、 ご辛抱いただきありがとうございます。社内から返信がありました。 ECCの「訂正」とは、SRAMに格納されている基となるビットを修正するのではなく、修正されたデータをCPUに返すことを意味します。自動修復には、別途スクラブ／ライトバック機構が必要です。 ソフトウェアスクラブを使用する際の推奨フロー: ECCは読み取り時にデータを訂正します。 シングルビットエラー割り込み／ステータスが発生します。RM 6.3.1.1を参照してください。割り込みの発生源を特定する。MCM_LMPECR [ER1BR] =1 ソフトウェアが故障アドレスを読み込みます。MCM_LMPEIR[PEELOC] = 5'h08 - SRAM_Lからの1ビット訂正可能なECCイベントで、MCM_LMFAR故障アドレスを示します。 ソフトウェアは修正された値を同じアドレスに書き換えます。 新たなECC症候群が生成され、保存される。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction @Celeste_Liu さん、ご回答ありがとうございます。しかし、 MCM_LMFATR[PEFSIZE]に関する私の質問には答えていません。 「MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを決定できますか?もし可能なら、これをMCM_LMFARと併用して読み込み・正書き書き返し操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、その後同じアドレスに8ビットの書き込みを行いエラーを訂正できますか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビットの書き込みを行うことは可能でしょうか?