Embedded Intel® Core™ Processors
Communicate Intel® Core™ Hardware, Software, Firmware, Graphics Concerns
1194 Discussions

EEUpdate, EFI, Rewriting EEPROM Not Working

TMcKe1
Beginner
5,109 Views

I am trying to program the external EEPROMs (https://www.onsemi.com/pub/Collateral/CAT25320-D.PDF https://www.onsemi.com/pub/Collateral/CAT25320-D.PDF) for two Intel 82574 Network Adapters with firmware and MAC addresses using eeupdate64e.efi. The EEPROMs are on a carrier board for a Qseven Computer Module https://www.mouser.com/ds/2/31/EmQ-i2301_Datasheet-20140324-335403.pdf (https://www.mouser.com/ds/2/31/EmQ-i2301_Datasheet-20140324-335403.pdf). The issue I am having is, I can program the blank EEPROM on a new board using eeupdate64e.efi, but if I try to rewrite the same EEPROM afterward using eeupdate64e.efi, the program says it was successful but none of the bits in the firmware nor the MAC address actually changes, it stays the same as what I first programmed.

The data sheet for the EEPROM says it supports write protection through pin 3 on the IC (which is held high on the board) and through bits in the status register. Please let me know whether if write protection were enabled, EEUPDATE would fail with an error message or would show a successful prompt. Also, if it were not able to program because of the status register, please let know if there is a way to use EEUPDATE or some other utility to change the register so that the EEPROM is writable. Please also let me know any reasons you can think of why I would be able to program the memory once, but not rewrite it afterward.

0 Kudos
9 Replies
CarlosAM_INTEL
Moderator
2,079 Views

Hello, antatm:

Thank you for contacting Intel Embedded Community.

Based on the information stated in your previous communication, we suggest you address all your "QSeven Computer on Module" consultations by filling out the form as a reference stated at:

https://www.arbor-technology.com/gl/Form/ContactUs https://www.arbor-technology.com/gl/Form/ContactUs

We hope that this information may help you.

Best regards,

Carlos_A.

0 Kudos
TMcKe1
Beginner
2,079 Views

Carlos,

Thank you for the response, I will ask them as well.

But to clarify, the carrier board with the two NIC's and two EEPROMs is not an Arbor product, it is a board we build ourselves for our customer that connects to an Arbor Qseven with an MXM connector.

I am looking to rule out EEUPDATE as the issue, please confirm whether or not there is a way to enable/disable write protect on an external EEPROM using EEUPDATE. Please confirm there would be no way to tell if it were enabled using EEUPDATE; that trying to program the EEPROM would show a success prompt not an error despite nothing changing.

0 Kudos
CarlosAM_INTEL
Moderator
2,079 Views

Hello, antatm:

Thanks for your clarification.

Based on your previous message, could you please let us know the sources that you have used to implement your design? By the way, could you please confirm if it has been reviewed by Intel?

Waiting for your answer to these questions.

Best regards,

Carlos_A.

0 Kudos
TMcKe1
Beginner
2,079 Views

Carlos,

We are a contract manufacturer building this product for our customer who contracted the design to a third party, so I am not sure if Intel reviewed the design. It is an existing design with finished product that does work, I can send you the schematic if that would help.

Our customer originally provided us with a second 32-bit Qseven board from Congatec, and an SSD with the 32-bit Windows version of eeupdate, and told us we could only use that to program the EEPROMs; nothing else would work. We were able to write the EEPROMs that way until the 32-bit Qseven stopped working. What I've been trying to do is program the EEPROMs with the 64-bit Qseven that is supplied with the carrier in the finished product and a 64 bit version of EEUPDATE. I don't see why the 32-bit Qseven would be able to do it and the 64-bit one wouldn't.

Regards,

Travis McKenna

0 Kudos
yyinx
Beginner
2,079 Views

Hi Carlos A

Could you provide the latest eepromARMTool ?and It can support the 82583V?

Thanks!

0 Kudos
CarlosAM_INTEL
Moderator
2,079 Views

Hello, antatm:

Thanks for your reply.

Based on your previous communication, could you please tell us the versions of Eeupdate you are attempting to be used?

By the way, could you please explain us if you have the ability to write the eeprom chips externally before putting them on the board?

Could you please contact the manufacturer of the affected device to send its design to be verified by the Intel schematic and layout review team? The procedure related to this can be found at the following website:

https://edc.intel.com/Tools/Design-Review/Default.aspx?language=en&r=717923153

Could you please let us know if the affected design is doing a full power cycle after writing?

Also, could please clarify if you were given the Eeupdate from an upstream supplier that has an NDA in place with Intel?

Please let us know all the information that should answer these questions.

Best regards,

Carlos_A.

0 Kudos
CarlosAM_INTEL
Moderator
2,079 Views

Hello, lyx:

Thank you for contacting Intel Embedded Community.

The Intel(R) 82583V Gigabit Ethernet Controller is unrelated to eepromARMTools.

We hope that this information may answer your questions.

Best regards,

Carlos_A.

0 Kudos
TMcKe1
Beginner
2,079 Views

Carlos_A,

The unit is not doing a power cycle after writing, and if it should, I think that is the issue. I just tried changing the MAC again on a board that I thought was not letting me overwrite it; when I ran eeupdate /mac_dump the MAC was the same, but when I read the chip with eeupdate /gui the first 6 bytes were changed. When I power cycled the board and ran eeupdate /mac_dump again, it output the new MAC address. Wherever the address is cached that eeupdate is reading from must not update until the device restarts.

The future plan is to have the chips written externally as you suggest.

Thank you for your help.

Regards,

Travis McKenna

0 Kudos
CarlosAM_INTEL
Moderator
2,079 Views

Hello, antatm:

Thanks for your reply.

We want to confirm for you that the best practice is to power cycle any device after the firmware is written. This ensures that the process worked.

We hope that this information may help you.

Best regards,

Carlos_A.

0 Kudos
Reply