TDA4VM: VTM -- TDA4 reset at the degree of 116C

Hi,

The driver configures at around 123C shutdown temperature. +/- 2 degree accuracy. So is expected to shutdown around 121C at best. 116C is too low.
Could you check what 0x304 maps to in the temperature conversion table?

- Keerthy

Hi Keerthy

0x304 = 772 =125C,

I did some tests with our board  and Ti demon board，set MAXT_OUTRG_ALERT_THR to 485 (0x1E5), 75C,

Then read temperature by "cat /sys/class/thermal/thermal_zone*/temp" every 0.1 seconds.

devmem2 0x42050010 w 0x01A501E5

Custom TDA4: dead line is 70C
70015
69155
69155
71513
69800

Custom Dra821: dead line is 73C
73341
73541
73142

Ti TDA4 demon board: dead line is 80C
80055
80055
80664
81676
80258

Thanks!

Dear Keerthy
   More information is that our custom board with one dra821, two tda4 (just name them tda4A and tda4B)

While set MAXT_OUTRG_ALERT_THR  to to 485 (0x1E5), 75C for all of the three.

dra821 and tda4B warm reset at  73C, 
tda4A warm reset at 70C.

May it caused by  hardware design?

Thanks!

Hi,

You are printing from the Linux console. So there might be a shutdown before the next higher temperatures print appears on the console. +/- 2c variation is expected. 

Regards,

Keerthy

Hi Keerthy

    As I test in our environment, it cost about more than 30 seconds (39.9seconds actually) to increase to 73C from 69C by linux console, so I don't think it should not be this case.

thanks!

Hi Keerthy

     Test another board, it reset at 73C，it seems that some single have issue, is it so？

thanks！

Hi,

https://www.ti.com/lit/pdf/sprz455

Errata i2128 impacts TDA4 & the TDA4 software implements work around to do a software trimming method & that requires the sample to have
efuses blown to assist the software trimming. So the TDA4A might be slightly off because of that. DRA821 does not have the errata so the accuracy will be higher.

- Keerthy

Hi Keerthy

    Set MAXT_OUTRG_ALERT_THR to 485 (0x1E5), 75C. 

    After I change "workaround_needed" to hard code in drivers/thermal/k3_j72xx_bandgap.c, it works ok, 73C to warm reset.

But the codes confused me.

drivers/thermal/k3_j72xx_bandgap.c

const struct k3_j72xx_bandgap_data k3_j72xx_bandgap_j721e_data = {
	.has_errata_i2128 = 1,
};

static int k3_j72xx_bandgap_probe(struct platform_device *pdev)
{
...

	driver_data = of_device_get_match_data(dev);
	if (driver_data)
		workaround_needed = driver_data->has_errata_i2128;

...

	/* Workaround not needed if bit30/bit31 is set even for J721e */
	if (workaround_needed && (readl(bgp->fuse_base + 0x0) & 0xc0000000) == 0xc0000000)
		workaround_needed = false;

	dev_info(bgp->dev, "Work around %sneeded\n",
		workaround_needed ? "not " : "");

	if (!workaround_needed)
		init_table(5, ref_table, golden_factors);
	else
		init_table(3, ref_table, pvt_wa_factors);

...		
}

Case 1:

In one custom TDA4 board, WKUP_SPARE_FUSE0[31:30] = 0b00, but the driver k3_j72xx_bandgap.c don't execute work around code.

[root@AOS ~]# devmem2 0x43000300

0x2BB2AAEC

WKUP_SPARE_FUSE0[31:30] = 0b00

Case 2:

Another custom TDA4 board, WKUP_SPARE_FUSE0[31:30] = 0b11, the driver execute work around code.

[root@AOS ~]# devmem2 0x43000300

0xEDB6CAED

WKUP_SPARE_FUSE0[31:30] = 0b11

Note: For the two boards, with WKUP_SPARE_FUSE0[31:30] = 0b00 or 0b11, they both need "work around", or they will warm reset at 70C 

Can you help review the code again?

Thanks!

Hi,

The print is inverted. The logic is that if the bit30/31 are set then even for j721e the work around is not needed. For other cases of j721e we need to apply the work around.

Driver executing as expected but print is inverted and it is fixed in future SDKs.

Regards,

Keerthy

Hi Keerthy

    But as my test, the boards are not executing as expected.

Set workaround_needed = true/false; before if (!workaround_needed),

And Set MAXT_OUTRG_ALERT_THR to 485 (0x1E5), 75C. 

static int k3_j72xx_bandgap_probe(struct platform_device *pdev)
{
...

	driver_data = of_device_get_match_data(dev);
	if (driver_data)
		workaround_needed = driver_data->has_errata_i2128;

...

	/* Workaround not needed if bit30/bit31 is set even for J721e */
	if (workaround_needed && (readl(bgp->fuse_base + 0x0) & 0xc0000000) == 0xc0000000)
		workaround_needed = false;

	dev_info(bgp->dev, "Work around %sneeded\n",
		workaround_needed ? "not " : "");

    workaround_needed = false;
    //workaround_needed = true;
    
	if (!workaround_needed)
		init_table(5, ref_table, golden_factors);
	else
		init_table(3, ref_table, pvt_wa_factors);

...		
}

Result:

Thanks!

Hi,

Thanks for the table.

The above is doing well. +/-3C accuracy for 75C.

Now for the workaround needed = false case:

This is slightly off but still resetting around 72C. The above 2 cases are the ones that happen with the code we have on the SDK.

Do you have concerns with the 3 degrees inaccuracy?

- Keerthy

Hi Keerthy

     Sorry for mistake the table, workaround_needed = false is ok for 0b00,

Do you have concerns with the 3 degrees inaccuracy?

Can it be changed to 0 degree?

Thanks!

Hi Li Ning

    I test it on j7200-evm, when mpu-thermal is about 123, system reboot

121270
122356
119078

121270
122356
118605

121425
122511
119235

121425
122356
118763

U-Boot SPL 2021.01-ga169f42610 (Sep 14 2022 - 14:30:44 +0000)
Model: Texas Instruments K3 J7200 SoC
Board: J7200X-PM2-SOM rev E6
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE: BL31: v2.6(release):v2.7-rc0-dirty
NOTICE: BL31: Built : 14:28:44, Sep 14 2022
I/TC:
I/TC: OP-TEE version: 3.17.0-125-g15a746d28 (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Wed Sep 14 14:29:02 UTC 2022 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

Have you checked the CTRLMMR_WKUP_RESET_SRC_STAT in order to verify the cause of the reset?

Kevin