[i.MX93] temperature grade is wrong

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

[i.MX93] temperature grade is wrong

Jump to solution
468 Views
yoooh8668
Contributor III

Hi,

I found the imx93 (rev.beta) does not match the temperature grade as it should be.

Here is the picture and its uboot log:

REV.beta

 

U-Boot 2023.04-00263-g7c7dd0dc2b0 (Apr 19 2024 - 15:50:35 +0800)

CPU:   i.MX93(52) rev1.0 1700 MHz (running at 1692 MHz)
CPU:   Consumer temperature grade (0C to 95C) at 51C

 

1.jpeg

REV.GA

 

U-Boot 2023.04-00263-g7c7dd0dc2b0 (Apr 19 2024 - 15:50:35 +0800)

CPU:   i.MX93(52) rev1.1 1700 MHz (running at 1692 MHz)
CPU:   Consumer temperature grade (0C to 95C) at 35C

 

2.jpeg

and here is the reference picture:

 
 
 

2023-11-08_13-58-59_的螢幕擷圖.png

 

 

 

I'm afraid that the detect code in uboot is not correct.

 

//arch/arm/mach-imx/imx9/soc.c
u32 get_cpu_temp_grade(int *minc, int *maxc)
{
        int ret;
        u32 val;
        ret = fuse_read(2, 3, &val);
        if (ret)
                val = 0; /* If read fuse failed, return as blank fuse */

        val >>= 4;
        val &= 0x3;

        if (minc && maxc) {
                if (val == TEMP_AUTOMOTIVE) {
                        *minc = -40;
                        *maxc = 125;
                } else if (val == TEMP_INDUSTRIAL) {
                        *minc = -40;
                        *maxc = 105;
                } else if (val == TEMP_EXTCOMMERCIAL) {
                        if (is_imx93()){
                                /* imx93 only has extended industrial*/
                                *minc = -40;
                                *maxc = 125;
                        } else {
                                *minc = -20;
                                *maxc = 105;
                        }
                } else {
                        *minc = 0;
                        *maxc = 95;
                }
        }
        return val;
}

 

 THANKS~~

Tags (2)
0 Kudos
1 Solution
322 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

The last release that is supported on A0 revision is Linux 6.1.22_2.0.0.

But I confirmed that behavior on our EVK. This could be caused by placeholder on the code, or this feature could not be implemented on the pre-production revision.

Best regards.

View solution in original post

0 Kudos
5 Replies
429 Views
opedis
Contributor III
In the picture, the Q(Qualification leve) is "P".

Maybe that is problem. It is just a samples. Not a mass production.
0 Kudos
421 Views
yoooh8668
Contributor III
I think so, but wait for official reply.
0 Kudos
437 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

That is strange since the part number indicates that correspond to an industrial part number.

Is this happening on other REV.beta devices?

Which are the software versions that you are using?

From what I have understood, the detect code in U-boot works as expected. It would be too strange if fuse values of device are wrong.

Best regards.

0 Kudos
422 Views
yoooh8668
Contributor III
Hi,
There are 4 piece of this sample(rev.beta) , all of them show the same result.

The branch is v2023.04_6.1.55_2.2.0 with our commits on it.
And there is no modifies on `arch/arm/mach-imx/imx9/soc.c` .

Maybe only the mass production can support this function(reg)?
Thanks~~
0 Kudos
323 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

The last release that is supported on A0 revision is Linux 6.1.22_2.0.0.

But I confirmed that behavior on our EVK. This could be caused by placeholder on the code, or this feature could not be implemented on the pre-production revision.

Best regards.

0 Kudos