I211 iNVM security lock not working ?

[JDe_S8]

Hello,

in my design with I211 it looks like the iNVM security lock can not be activated.

The eeupdate tool always reports that the iNVM is not locked (/INVMISLOCKED option), although the INVM contains the special 'lock setting' (bit15 set in iNVM word 0x0A).

The iNVM was programmed with a MAC address and the standard Intel "I211_Invm_NoAPM_v0.6.txt" but with:

WALD 0x0a = 0xC02F PCIE_RST ; [Intel] Set GPAR_EN + iNVM LOCKED

The contents of the iNVM read back through the PCIe BAR0 are correct:

12120: 19 00 00 15 19 02 BA FF - 19 04 DA 02 02 00 E8 16

12130: 41 15 00 00 02 00 8D 03 - 21 3C 40 0B 11 14 2F C0

12140: 11 36 00 34 11 1A 39 15 - 11 42 84 05 11 48 80 02

12150: 19 1E 43 73 1A 00 00 00 - 41 02 10 08 02 00 D1 16

12160: A8 00 FF 00 02 00 D0 16 - 90 00 00 5E 00 00 00 00

12170: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

12180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

12190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

121A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

121B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

121C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

121D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

121E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

121F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

12200: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

12210: 00 00 00 00 30 00 00 01 - 81 84 88 46 A0 52 B2 48

Pin12 (SECURITY_EN) is pulled up to 3.3V with 10k, nothing else connected. According to the documentation this pin is sampled at the rising edge of LAN_PWR_GOOD, which is connected to the powergood signal of the 3v3 supply. I verified with the oscilloscope that Pin12 is already high when the rising edge on LAN_PWR_GOOD occurs, so the "invm security" should be enabled.

The only thing I notice is that after approx 30ms, the Pin12 is driven low by the I211 (probably used for NVM_SI?), and the pin is still low when PE_RST_N deasserts. So in case that the I211 would also sample the pin level when the PCIe reset goes away, it could explain why I can't enable the iNVM Lock.

How does the EEUPDATE program determines the iNVM locked state ? I can't find any register where the actual locked state can be read from.

Any help appreciated,

thanks,

Jon

[CarlosAM_INTEL]

Hello, jonds:

Thank you for contacting Intel Embedded Community.

In order to better understand this situation, could you please confirm if this problem happens with the EEUpdate version 5.29.5.2? In case that you are using a different version, please use the cited version that can be found in thehttps://edc.intel.com/Link.aspx?id=3815 Intel Network Connections Tools 22.4 PV LAN Software Tools document # 348742, and let us know the results.

Waiting for your update.

Best regards,

Carlos_A.

[JDe_S8]

yes, I am using EEUPDATE v5.29.05.02 (the latest I could find in the '348742_Quartzville_Tools_460903'), the Win32 version.

[CarlosAM_INTEL]

Hello, jonds:

Thanks for your update.

In order to better understand this situation, could you please let us know how many designs have been affected and how many have been produced?

Also, could you please tell us if your design has been reviewed by Intel? In case that your answer is negative, please follow the procedure stated at the https://edc.intel.com/Tools/Design-Review/Default.aspx?language=en Intel Design Review Services website to review your project.

Waiting for your answer to these questions.

Best regards,

Carlos_A.

[JDe_S8]

Hi Carlos,

it occurs on both prototype boards I have here.

It was not reviewed by Intel.

But the schematic is quite straightforward (see picture)

I did not experiment yet with connecting XO to GND.

Are you able to enable the security lock on some I211 design and read it back with the EEUPDATE tool ?

How does the EEUPDATE program determines the iNVM locked state ?

[CarlosAM_INTEL]

Hello, jonds:

Thanks for your update.

We are working to give you an update as soon as possible.

Thanks for your patience and understanding.

Best regards,

Carlos_A.

[CarlosAM_INTEL]

Hello, jonds:

We apologize for the delay to give you an update.

Could you please try to use eeupdate /INVMLOCK option to "Lock" the INVM? After this procedure that can help you to compare INVM memory and see the differences.

/INVMISLOCKED

Checks if autoload configuration stored in OTP

memory is protected against write attempts.

/INVMLOCK

Sets unique record in autoload configuration stored in INVM

protecting its content against further updates.

We hope that this information may help you.

Best regards,

Carlos_A.

[JDe_S8]

Hello,

in the meanwhile I found out that the security lock is really working, but that the EEUPDATE program (v5.29.05.02) is not correctly displaying the status with the /INVMISLOCKED option.

It will only report it LOCKED when the config contains a write to iNVM word 0xA with bit15 set where the reset type is set to type '00'. When using another reset type, the EEUPDATE program reports it 'unlocked' although it is in reality locked as well and a verification error is returned when attempting to change iNVM config data.

The SECURITY_EN pin strapping on my board is working fine as well (shorting the pin to GND, allows writing data again).

Using the /INVMLOCK option adds a config word to write iNVM 0xA with the fixed value 0xA02F and reset type 00; but this would override any other value you would want to write to 0xA, so I guess this option could not always be used.

Conclusion: Intel should fix the EEUPDATE tool.