Possible Functional Differences in MCIMX6Y2CVM08AB – Seeking Clarification

[Marlon]

Dear NXP Commun7ity,

I have encountered an unusual issue with one of the MCIMX6Y2CVM08AB processors used in my PCB production. Below are the observed symptoms:

1. USB ID Mismatch

All chips are labeled MCIMX6Y2CVM08AB on the surface.

lsusb shows the faulty chip with USB ID 15a2:007d, while others report 15a2:0080.

Both IDs work with imx_usb/uuu for firmware loading, but ddr_stress_test fails to recognize the 15a2:007d device.

2. DCP-Related Segmentation Fault in U-Boot

During U-Boot initialization, the chip crashes when accessing the DCP module:

uclass_get_device_by_driver(UCLASS_RNG, DM_DRIVER_GET(dcp_rng), &dev);

Suspected DCP hardware failure or misconfiguration.

3. Linux Boot Failure

U-Boot successfully decompresses the kernel (bootm 0x80200000 - 0x80300000), but Linux halts silently after decompression.

Preliminary suspicion: MMU module corruption or initialization issue.

Questions:

--------------------------------

USB ID Interpretation:

What do the two USB IDs (15a2:007d vs. 15a2:0080) signify for the i.MX6ULL series? Are they tied to specific variants?

DCP Functionality:

Could DCP operation be affected by external power supply or I/O states?

Does the entire i.MX6ULL series include the DCP module, or are there exceptions?

Hypotheses:

--------------------------------

Counterfeit Chip:

Did I receive a lower-spec i.MX6ULL variant (without DCP) mislabeled as MCIMX6Y2CVM08AB? The USB ID discrepancy hints at possible remarking.

Heat Damage During Soldering:

Could excessive soldering temperatures have damaged the DCP/MMU modules, causing erratic behavior in U-Boot and Linux?

Request for Guidance:

--------------------------------

Any documentation or insights on USB ID differences in i.MX6ULL?

Known DCP-related errata or initialization requirements?

Recommended debugging steps to isolate the root cause (e.g., JTAG analysis, register checks)?

Thank you for your support!

[Marlon]

Enable Linux earlyprintk to trace execution locations.

When Linux executes the modification of the periph_pre clock, the CPU hangs. The call stack is as follows:

start_kernel() init/main.c

time_init() arch/arm/kernel/time.c:time_init()

of_clk_init() driver/clk/clk.c

imx6ul_clocks_init() driver/clk/imx/clk-imx6ul.c

imx_clk_set_parent(clks[IMX6UL_CLK_PERIPH], clks[IMX6UL_CLK_PERIPH_PRE]);

Current state and output:

```

[ 0.000000] Booting Linux on physical CPU 0x0

[ 0.000000] Linux version 4.14.98-g83ba4ea05-dirty (dev-wml@debian) (gcc version 9.3.1 20200408 5

[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d

[ 0.000000] CPU: div instructions available: patching division code

[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[ 0.000000] OF: fdt: Machine model: GLink Router Freescale i.MX6 ULL 14x14 EVK Board

[ 0.000000] bootconsole [earlycon0] enabled

[ 0.000000] Memory policy: Data cache writealloc

[ 0.000000] Reserved memory: created CMA memory pool at 0x98000000, size 128 MiB

[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool

[ 0.000000] Hit pending asynchronous external abort (FSR=0x00000c06) during first unmask, this i.

[ 0.000000] percpu: Embedded 17 pages/cpu @97b8b000 s39116 r8192 d22324 u69632

[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 130048

[ 0.000000] Kernel command line: console=ttymxc0,115200 ubi.mtd=5 rw root=ubi0:rootfs rootfstypek

[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)

[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

[ 0.000000] Memory: 368288K/524288K available (10240K kernel code, 1026K rwdata, 3572K rodata, 3)

[ 0.000000] Virtual kernel memory layout:

[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)

[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)

[ 0.000000] vmalloc : 0xa0800000 - 0xff800000 (1520 MB)

[ 0.000000] lowmem : 0x80000000 - 0xa0000000 ( 512 MB)

[ 0.000000] pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)

[ 0.000000] modules : 0x7f000000 - 0x7fe00000 ( 14 MB)

[ 0.000000] .text : 0x80008000 - 0x80b00000 (11232 kB)

[ 0.000000] .init : 0x81000000 - 0x81300000 (3072 kB)

[ 0.000000] .data : 0x81300000 - 0x81400bc4 (1027 kB)

[ 0.000000] .bss : 0x81402000 - 0x81474338 ( 457 kB)

[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

[ 0.000000] ftrace: allocating 36500 entries in 108 pages

[ 0.000000] Hierarchical RCU implementation.

[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.

[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1

[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16

--------------- CPU stop at here ---------------

```

After commenting out the imx_clk_set_parent() function, Linux can continue execution. At the end, you can see the kernel output:

random: crng init done

```

[ 1.075046] genirq: Setting trigger mode 3 for irq 30 failed (irq_chip_set_type_parent+0x0/0x38)

[ 1.084927] Unhandled fault: imprecise external abort (0xc06) at 0x00000000

[ 1.092012] pgd = 80004000

[ 1.094823] [00000000] *pgd=00000000

[ 1.098523] Internal error: : c06 [#1] SMP ARM

[ 1.103074] Modules linked in:

[ 1.106253] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.98-g83ba4ea05-dirty #995

[ 1.114032] Hardware name: Freescale i.MX6 UltraLite (Device Tree)

[ 1.120323] task: 94128000 task.stack: 94126000

[ 1.124980] PC is at imx_pmx_set_one_pin_mem+0xa4/0x190

[ 1.130322] LR is at imx_pmx_set_one_pin_mem+0x4c/0x190

[ 1.135656] pc : [<804cdde0>] lr : [<804cdd88>] psr: 60000013

[ 1.142035] sp : 94127d00 ip : 94127d00 fp : 94127d24

[ 1.147370] r10: 813639a4 r9 : 941ff090 r8 : 813640c4

[ 1.152706] r7 : 941fe950 r6 : 00000024 r5 : 941fe910 r4 : 941ff0d0

[ 1.159347] r3 : 00000000 r2 : a0840000 r1 : 00000000 r0 : 941fe910

[ 1.165992] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none

[ 1.173242] Control: 10c53c7d Table: 8000406a DAC: 00000051

[ 1.179100] Process swapper/0 (pid: 1, stack limit = 0x94126210)

[ 1.185220] Stack: (0x94127d00 to 0x94128000)

[ 1.189700] 7d00: 00000000 941fe910 00000002 00000014 813640c4 941ff090 94127d4c 94127d28

[ 1.198005] 7d20: 804ccd9c 804cdd48 941fa60c 00000002 941fa600 942722c0 942722d4 80d9bf04

[ 1.206311] 7d40: 94127d8c 94127d50 804cab04 804ccd14 8136399c 014080c0 941ff110 00000002

[ 1.214617] 7d60: 8136399c 941f7610 942722c0 9427228c 942721c0 00000000 00000000 94272280

[ 1.222921] 7d80: 94127dbc 94127d90 804c781c 804ca990 00000000 941f7610 00000000 94272150

[ 1.231226] 7da0: 94272150 81391804 00000000 00000000 94127dcc 94127dc0 804c7848 804c76e8

[ 1.239530] 7dc0: 94127dec 94127dd0 805b5798 804c7830 941f7610 81460e60 941f7644 81460e64

[ 1.247834] 7de0: 94127e1c 94127df0 8058c8c0 805b56e8 00000000 941f7610 81391804 941f7644

[ 1.256139] 7e00: 8137bc28 810a184c 810a182c 81401000 94127e3c 94127e20 8058cbc4 8058c820

[ 1.264443] 7e20: 00000000 81391804 8058cb04 8137bc28 94127e64 94127e40 8058ac18 8058cb10

[ 1.272749] 7e40: 9410f058 941eacb4 9410f06c 81391804 94270b80 00000000 94127e74 94127e68

[ 1.281053] 7e60: 8058c374 8058ab9c 94127e9c 94127e78 8058be50 8058c354 80de6d6c 94127e88

[ 1.289359] 7e80: 81391804 ffffe000 00000000 00000005 94127eb4 94127ea0 8058d80c 8058bcc4

[ 1.297664] 7ea0: 81065dd8 ffffe000 94127ec4 94127eb8 8058e920 8058d790 94127edc 94127ec8

[ 1.305970] 7ec0: 81065dfc 8058e8dc 81065dd8 ffffe000 94127f4c 94127ee0 80101bfc 81065de4

[ 1.314275] 7ee0: 94127f4c 94127ef0 80154e00 81000548 80d66eb0 80d66e90 80d66edc 80e05edc

[ 1.322580] 7f00: 80d66e6c 00000004 00000004 00000000 80d5c720 80e78e74 97fffa55 00000000

[ 1.330884] 7f20: 00000000 80e78e74 00000005 80e78e74 8125ade4 81401000 00000005 810a184c

[ 1.339190] 7f40: 94127f94 94127f50 81001108 80101bb4 00000004 00000004 00000000 8100053c

[ 1.347494] 7f60: 8100053c 00000113 80af258c 00000000 80af258c 00000000 00000000 00000000

[ 1.355799] 7f80: 00000000 00000000 94127fac 94127f98 80af25a4 81000fa4 00000000 80af258c

[ 1.364103] 7fa0: 00000000 94127fb0 801081e8 80af2598 00000000 00000000 00000000 00000000

[ 1.372406] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

[ 1.380709] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000

[ 1.389041] [<804cdde0>] (imx_pmx_set_one_pin_mem) from [<804ccd9c>] (imx_pmx_set+0x94/0xb8)

[ 1.397621] [<804ccd9c>] (imx_pmx_set) from [<804cab04>] (pinmux_enable_setting+0x180/0x234)

[ 1.406195] [<804cab04>] (pinmux_enable_setting) from [<804c781c>] (pinctrl_commit_state+0x140/0)

[ 1.415551] [<804c781c>] (pinctrl_commit_state) from [<804c7848>] (pinctrl_select_state+0x24/0x3)

[ 1.424648] [<804c7848>] (pinctrl_select_state) from [<805b5798>] (pinctrl_bind_pins+0xbc/0x140)

[ 1.433574] [<805b5798>] (pinctrl_bind_pins) from [<8058c8c0>] (driver_probe_device+0xac/0x2f0)

[ 1.442409] [<8058c8c0>] (driver_probe_device) from [<8058cbc4>] (__driver_attach+0xc0/0xc4)

[ 1.450982] [<8058cbc4>] (__driver_attach) from [<8058ac18>] (bus_for_each_dev+0x88/0xac)

[ 1.459294] [<8058ac18>] (bus_for_each_dev) from [<8058c374>] (driver_attach+0x2c/0x30)

[ 1.467427] [<8058c374>] (driver_attach) from [<8058be50>] (bus_add_driver+0x198/0x21c)

[ 1.475562] [<8058be50>] (bus_add_driver) from [<8058d80c>] (driver_register+0x88/0x104)

[ 1.483788] [<8058d80c>] (driver_register) from [<8058e920>] (__platform_driver_register+0x50/0x)

[ 1.492975] [<8058e920>] (__platform_driver_register) from [<81065dfc>] (i2c_gpio_init+0x24/0x44)

[ 1.501987] [<81065dfc>] (i2c_gpio_init) from [<80101bfc>] (do_one_initcall+0x54/0x174)

[ 1.510126] [<80101bfc>] (do_one_initcall) from [<81001108>] (kernel_init_freeable+0x170/0x208)

[ 1.518962] [<81001108>] (kernel_init_freeable) from [<80af25a4>] (kernel_init+0x18/0x124)

[ 1.527366] [<80af25a4>] (kernel_init) from [<801081e8>] (ret_from_fork+0x14/0x2c)

[ 1.535062] Code: e1d410b8 e594200c e0833001 e5832000 (e3a00000)

[ 1.541300] ---[ end trace 2fb4e2e5f32b3862 ]---

[ 1.546184] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[ 1.546184]

[ 1.555560] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[ 1.555560]

[ 3.148515] random: fast init done

[ 134.574857] random: crng init done

```

this is source code on linux

// driver/clk/imx/clk-imx6ul.c

static void __init imx6ul_clocks_init(struct device_node *ccm_node)

{

/* ------------------ */

/* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */

imx_clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL], clks[IMX6UL_CLK_PLL3_USB_OTG]);

imx_clk_set_parent(clks[IMX6UL_CLK_PERIPH], clks[IMX6UL_CLK_PERIPH_CLK2]);

imx_clk_set_parent(clks[IMX6UL_CLK_PERIPH_PRE], clks[IMX6UL_CLK_PLL2_BUS]);

// After executing this line of code, the CPU got stuck.

imx_clk_set_parent(clks[IMX6UL_CLK_PERIPH], clks[IMX6UL_CLK_PERIPH_PRE]);

imx_clk_set_rate(clks[IMX6UL_CLK_AHB], 132000000);

}

I have tested the stability of both VDD_SOC_IN and the 24MHz clock, and no abnormalities were found. Can we conclude that the chip is internally damaged?

[NEEDEOLCALL]

### Key Points
- The USB ID mismatch (15a2:007d vs. 15a2:0080) on your MCIMX6Y2CVM08AB processors likely indicates a difference in USB configuration or firmware, possibly tied to specific silicon revisions or manufacturing batches, rather than a variant change.
- The DCP (Data Co-Processor) module is standard across the i.MX6ULL series, including the MCIMX6Y2CVM08AB, and issues like segmentation faults suggest a configuration or hardware problem rather than its absence.
- Symptoms (DCP crash, Linux boot failure) could stem from hardware damage (e.g., soldering heat) or misconfiguration, but counterfeit chips or MMU corruption are also plausible hypotheses.

### Direct Answer

Thank you for sharing the details of your issue with the MCIMX6Y2CVM08AB processor. Here's an analysis and guidance based on the observed symptoms:

#### USB ID Interpretation
- The USB IDs 15a2:007d and 15a2:0080 are both associated with Freescale Semiconductor (now NXP) i.MX processors. The prefix "15a2" is NXP's vendor ID, while the device IDs (007d and 0080) likely correspond to different USB configurations or silicon revisions within the i.MX6ULL series. Specifically:
- 15a2:007d has been linked to devices like the EDIROL UA-101, suggesting an older or alternate USB interface configuration.
- 15a2:0080 is associated with the G-70, indicating a potentially updated or different USB mode (e.g., DCP functionality).
- These IDs do not necessarily indicate different processor variants but may reflect firmware settings, OTP (One-Time Programmable) memory programming, or manufacturing differences. The fact that both IDs support imx_usb/uuu suggests the USB PHY is functional, but the ddr_stress_test failure with 15a2:007d could indicate a compatibility issue or a defect affecting memory access.

#### DCP Functionality
- The DCP module is included across all i.MX6ULL variants, including the MCIMX6Y2CVM08AB, which features a Cortex-A7 core with integrated cryptographic acceleration (AES-128, SHA-1, SHA-256). A segmentation fault during `uclass_get_device_by_driver(UCLASS_RNG, DM_DRIVER_GET(dcp_rng), &dev)` in U-Boot suggests:
- A misconfiguration in DCP initialization (e.g., incorrect clock settings or memory mapping).
- Potential hardware damage affecting the DCP or its memory interface.
- External factors like power supply instability or improper I/O states (e.g., unconnected pins) could corrupt DCP operation, especially if voltage spikes occur during power-up. However, this would typically affect all chips unless the faulty unit experienced unique conditions.

#### Hypotheses Evaluation
- **Counterfeit Chip**: A mislabeled lower-spec chip (e.g., without DCP) is unlikely, as the MCIMX6Y2CVM08AB is a specific part number with a defined feature set, and both USB IDs are NXP-registered. The DCP crash suggests it exists but may be faulty or misconfigured, not absent.
- **Heat Damage During Soldering**: Excessive soldering temperatures (above the recommended 260°C peak reflow) could damage sensitive modules like DCP or MMU, leading to erratic behavior. This is plausible if the faulty chip was exposed to outlier conditions during assembly.

#### Recommended Debugging Steps
1. **JTAG Analysis**:
- Use a JTAG debugger (e.g., Segger J-Link or Lauterbach) to halt the processor and inspect DCP registers (e.g., DCP_CTRL, DCP_STAT) for error flags. Check if the DCP clock is enabled and memory access is valid.
- Verify MMU settings by dumping the page tables after U-Boot initialization to rule out corruption.

2. **Register Checks**:
- In U-Boot, manually probe the DCP configuration (e.g., `md.l <DCP_BASE>` where DCP_BASE is 0x2280000) to identify stuck bits or unexpected values.
- Check the OCRAM (On-Chip RAM) mapping with MMU enabled, as DCP requires direct access to it. Ensure the buffer addresses align with physical memory.

3. **Power and Signal Integrity**:
- Measure supply voltages (1.2V, 3.3V) and I/O pin states during boot using an oscilloscope to detect noise or brownouts that might affect DCP/MMU.
- Review the PCB layout for proper decoupling capacitors near the processor.

4. **Errata and Documentation**:
- Consult the i.MX6ULL Reference Manual and Errata document (available via NXP’s website) for known DCP or MMU issues. Look for errata related to USB ID variations or DCP initialization crashes.
- The Linux User Guide mentions DCP crypto key usage, which may require specific kernel patches if misconfigured.

5. **Firmware Reprogramming**:
- Re-flash the U-Boot and kernel images using imx_usb/uuu, ensuring the correct configuration for 15a2:007d. Compare the OTP settings between good and faulty chips if accessible.

#### Additional Insights
- The silent Linux halt after kernel decompression could indicate an MMU misconfiguration or memory corruption, possibly exacerbated by the DCP issue. If JTAG shows valid MMU tables but the system hangs, suspect DRAM initialization errors tied to the USB ID discrepancy.
- The ddr_stress_test failure with 15a2:007d suggests a memory interface problem, which could be a manufacturing defect rather than heat damage, especially if other chips pass.

#### Next Steps
Start with JTAG analysis to isolate the DCP/MMU issue, followed by power integrity checks. If the problem persists, contact NXP support with your findings (e.g., register dumps, soldering profiles) to request a deeper investigation into the USB ID variation and potential errata. This approach should help determine if the chip is defective, damaged, or misconfigured.

Let me know if you need further assistance with specific debug commands or tools!

[Bio_TICFSL]

Good!