Two BIOS chips/Dual BIOS/Q-Flash vs DMI data

Hello everyone,
I am a person who was doing the same things as people here but 15 years ago. BIOS, drivers, flashing apps mods, etc.
I am reading the forum, some things didn’t change, some others have blown my mind.
Some part of me wants to back… but studying all changes, discoveries, tools, knowledge from last decade would take me months. I am full of respect for the pro’s here.

In this topic, I want to ask about a nowadays way how BIOS(uefi) recovery methods work.

We all know that BIOS files provided by manufacturers have the same sizes as the BIOS chips. Flashing tools don’t write them 1:1 to the chips. Some areas on the chip are omitted during a flashing procedure. Serial numbers, MACs, all DMI data remain untouched. In the BIOS file, those areas are empty + flash tools know what places to omit. Making a raw copy with SPI external flasher gives us a full copy chip’s memory (BIOS+DMI+CMOS).

[Q1] Is there any tool that can make the chip’s raw copy from a software side? Confirmed 1:1 copy made with SPI?

Now let’s look at Dual Bios feature. In 2009 when I was making backups of two chips with SPI, only the main chip contained DMI data. On the second chip there were only data which were 1:1 copy of the BIOS file from the manufacturer’s website. No DMI data.

The main idea of that feature was flashing the ‘BIOS file’ to the MAIN chip. Second chip was treated only like a pendrive.
The MAIN chip was the only place where DMI data were saved.

If the MAIN chip was fully erased or just stopped working, there was no possibility to recover the mainboard with the original serial numbers, etc.

Let’s back to today. My mainboard is Gigabyte z490 Vision D. The second after z490 Aorus Xtreme, z490 flagship mainboard. On this MB there is only one BIOS chip. There is a place with 8 pads for the second chip but Gigabyte left it empty. Probably because I can always reflash my CHIP using USB and the Q-flash button.
But what if I overwrite or erase DMI data by a bad mod? The MB is gone… or I can have someone’s board SNs…

USB Q-flash and (like in the past) second BIOS chips are working recovery methods but only when the MAIN chip still has DMI data.

So if one of the flagship MB has one BIOS chip and USB as the recovery method, I suppose that MBs with two chips, like in the past, has the MAIN chip with DMI and the second chip is only memory with one of the older BIOS file with no DMI data.

So what it looks today? I have one BIOS chip so I have DMI only in one place.

What about nowadays MB with two chips? Has anybody checked with SPI what they really contain?

Sorry but I would never want to have MB with someone’s DMI…

I am the most courious what is written on the BIOS chips on MBs with a switch for selecting BIOS.
Do they both contain DMI and are 1:1 copy before flashing anything?
Or they are only the memory for “the BIOS file” and DMI is written in the other place?

So my question is really:
How it looks today? Did the manufacturers still keep DMI data in one place? Or some manufacturers are user-friendly. Is it possible to get the 1:1 dump of the MAIN chip using a software?

Best Wishes :slight_smile:

use Intel FPT and unlock region spi locked
use my new method in here
https://winraid.level1techs.com/t/guide-usage-of-ami-s-aptiov-uefi-editor-better-than-amibcp/

and Very detail about region
https://winraid.level1techs.com/t/guide-unlock-intel-flash-descriptor-read-write-access-permissions-for-spi-servicing/32449

full dump tutorial here
fptw64.exe -D FullDump.bin
https://github.com/mostav02/Remove_IntelME_FPT

1 Like

Thank you rofikkernel.
I started to write my post 10 minutes after I had read your post from the first link :slight_smile: Have you compared the dump with that from the SPI? I know FPT but I don’t feel sure about it. Intel+easyness to access some critical areas+better than manufacturer’s tools… where is a bait… probably I will never trust it until I’ll make an external dump. Yesterday I managed to catch the chip with a Chinese clip but it has 256Mbit, 300mils and it is fairly low so there have to hold the clip with fingers. 5% and my fingers were white. Maybe it would be easer to unsolder it.

BTW. I am thinking about soldering the second chip to that empty place. Have somebody tried that here? Electric tracks look like prepared for that.
Let’s suppose that the BIOS blocks recognizing this second chip. What area of the BIOS is responsible or could be for that blocking? Do we have any information about that? (sorry but I still try understand all possibilities of ME)

Update:
fptw64.exe -D
2 years ago I found that app. Probably in the zip contains ME drivers to my MB. I dumped all regions but I still remember that a small red light turned on.
‘fptw64.exe -d gbe.fpt -gbe’ command ended with a message ‘no GbE region found’. I thought then ‘I have 2 NICs… doesn’t GbE is an acronym of GbEthernet? Apparently not. For last 10 years I haven’t tracked any knowledge that type, so it can be…’. Later, of course, I read something about Intel MBs firmware and having in my mind ‘the lack of GbE’, I started to think that FPT doesn’t have possibility to read the whole firmware.

Above, when I wrote ‘BIOS’, I thought about ‘SPI’. When I wrote ‘SPI’, I thought about ‘Serial Peripheral Interface’ programmer or dump made by it :face_exhaling:

I probably look like a cave man who just went out from his hideaway.

Finally, I want to ask you about one thing.
Just tell me that the idea of dividing the firmware (SPI) in that way comes from IEEE, etc. but not from Intel :neutral_face:

github tutorial like more promising
https://github.com/mostav02/Remove_IntelME_FPT

first check status locked unlocked first


first flash descriptor must unlocked

use my tutorial to unlock bios lock with efi shell search string extracted from ifr
The common search terms are “Me FW Image Re-Flash”, “ME/TXE Disable”, “HMRFPO”, “Disable SPI/BIOS Protection” but not limited to. You may carefully inspect the extracted information and look for options that intuitively sound related to flash/service/unlocking.

after unlocking you can dump all, you cannot using fptw -d -gbe gbe.bin not like that


use -d only for full dump, only BIOS and ME can do that per region

Conclusion : if you only modified bios and dont want lose GBE(MAC lan),etc , as long as you flash modified bios with -bios command, it only touch bios region not messed up with other

Update: only follow my guide at first unlock bios lock & fprr only i can dump gbe too ,see here

and here with only fptw.exe -d bios only,it not contain other gbe
image

Nice. You make a great job. Thank you for all information you provided.
I’m sorry that I cannot answer you all I want.
It’s Chistmas time and I am not at home right now. In few days I am back and I will use your method and read the chip externally. Then compare two files.

I thought about something when reading your last post. My MB has two NICs - i225-V and i219-V.
Did you read my post from yesterday about the OTP area in the flash memory chip of i225-v?
I removed that post today… That card has its own 2MB chip with MAC, eeprom, firmware and 64bytes of OTP (which I’m acually searching).

Here is a copy of that post. I want to show it because I have noticed something in your screenshots.

> Hello,
> Thank you for a possibility to write a topic on a such profesional forum.
> It is my first post here. It is caused mainly by a difficult problem that I believe I’ll get some help here.
> 
> Let’s start. Probably most of users heard about issues with the Intel Ethernet card i225-V on a chipset Z490. i225-v card is the 2.5GbE card and Intel suggested all mainboards producers to use that card in their “higher class” mainboards. It appeared that this card has many bugs. They tried to fix them by changing firmware in rev.2, next they released rev.3. People had more and more problems, new bugs were discovered. Then… Intel decided to stop a project “i225-V” and released i226-V. They even did not want to fix them. On my mainboard there is a second NIC Intel i219-V rev.11. I225-V had only 3 revisions. They had to find a really big bug in the architecture of that card.
> 
> I have the mainboard Gigabyte Z490 Vision D. My 2.5Gbps NIC is i225-v rev.2. I didn’t need a speed, etc. Just stability. I updated the firmware to 1.45. All producers released that update. Intel claimed that this firmware will solve all problems… But since a first second there appeared next problems. The firmware could be updated only on the old drivers. Fortunately for me, everything went smooth. As I said, I wanted stability, not speed. I never measured its possibilities. Before updating NIC worked quite good, after also. Everything was OK for 2 months. Then the card started to loose some packets every 30 seconds. It looked that way (as example): I was reading news and clicked 4 articles to open in new tabs. 3 of them appeared imediately but 4th not. To open that site I had to click F5/refresh. Even refreshing after “0.01s” worked. Day by day it was anoying me much more. Finally I decided to do something with it.
> 
> I found newer firmwares. I believed they are for rev.3 but unofficially I got an information that they are universal. There were version 1.57, 1.68, 1.7?.. I updated the firmware to 1.57 version and my problem was gone. It satisfied me and didnt update to higher version.
> 
> Small info about i225-V. It is a normal IC with firmware located on a flash memory chip. The firmware’s size has about 400KB. Asus uses 1MB flash memory chip. Gigabyte uses 2MB flash memory chip… almost 1.5MB are zeros. From 0x100000-0x200000 are only zeros…
> 
> One day I had a lot of free time. I wanted to find the reason of loosing packets in 1.45 firmware. Few weeks before I read that Gigabyte had put in factory the i225-V eeprom with the wrong checksum and someone provided proper values (look at Google: hackintosh gigabyte z490 i225v fix).
> I thought it was needed to run that NIC card on hackintosh and nothing else.
> 
> I prepared tools to analyze files. I dumped 1.57 and compared it to my backup of 1.45. And my “everything” dropped down…
> 
> Quick info:
> The backup has the same size as flash memory and is 1:1 copy. It looks like:
> 
> [eeprom—
> eeprom—
> firmware—
> empty_space—
> some_bytes—
> empty_space]
> 
> The firmware update file also has the same size but looks like:
> 
> [generic_eeprom—
> flash_app—
> firmware—
> empty_space]
> 
> … 1.57 dump looked:
> 
> [eeprom—
> eeprom—
> firmware1.57—
> empty_space—
> some_bytes—
> empty_space—
> firmware1.57—
> empty_space—
> some_bytes—
> empty_space]
> 
> I knew that something is wrong. (BTW. updating to 1.57 was not easy. My language skills make it impossible to describe tricks and fooling software that I used in that process. I’m sorry.)
> When I set Intel app in recovery mode and provided the link to my backup, I saw “incorrect checksum” on the screen.
> I connected everything together in my mind. Because Gigabyte provided mainboards with corrupted checksum of i225-v firmware, now Intel’s app recognized it as the incorrect backup.
> Probably also, the wrong values in eeprom caused double flashing of the new firmware.
> 
> The correct firmware starts at 0x2000.
> My second copy started at 0x7D000.
> In that place there should be zeros.
> “Some bytes” I mentioned above were couples of bytes but they were in the places which suggested that they are not random at all. Like 0x76000, 0x7A000, 0x7C000, and few more.
> 
> Writing in eeprom corrected values didnt help. I was so upset. I ‘borrow’ from China the latest as possible apps eeupdate, lanconf, celo. They were in the versions which saw all new Intel NIC including i225-V.
> 
> Warning: Those programs are too dangerous. Please don’t look for them if there is no reason! (They allow to modify raw eeprom [but you cannot change every values - the main unit will modify other values to keep the proper checksums - your changes will be rejected if there won’t be the way to make it]. They can modify values of everything - registers, the way of the connecting with BUS. One wrong number and your device is bricked. The huge part of changes cannot be reversed. Furthermore, you can change (the app allows to fool itself) a VID value of any device connected to the PCIE BUS (temporary). For example I can set VID of DDR4 controller or WiFi card to 15F3. That value is the real VID of i225-V. From that moment, the app would see those devices as i225-V card and allows you to see and modify found parameters. Fortunately 95% of devices on the BUS are secured and don’t allow you to even access them at this level. But still about 5 devices access you to mess their PCIE parameters. It is too dangerous for those devices to play with that apps unless you know exactly what you want to do.
> 
> For example: Searching the way for remap the flash chip, I changed “writing style” from Atmel to SST. Now SST mode is shown as default. I can change to Atmel but after reboot, SST mode comes back. So you can see how easy is to set the unreversable option. BTW. How do you think, where that change was saved? In the eeprom of the main chip? Did someone discover the method of communication with this 48legs bug-bucket chip?
> 
> I made almost 100 different prepared flash files trying to step by step get back the flash memory to the normal look. The funny thing is that card was still working all the time. Despite using so powerful programs like lanfconf and eeupdate, the card blocked every try of flashing. I found the way to bypass that. After dozens of flashing tries with on or off different security options, the card started to work so slow (responses after 20s from commands) that it was possible to write 3% of the flash memory with the other flasher. That means eeprom and the begining of the first firmware. Modifing values in eeprom allows me set the adresses where the main chip of i225-V wrote firmware…
> 
> I managed to save parts in different ways:
> 
> [eeprom1.45—
> eeprom1.57—
> firmware1.57—
> empty_space–
> some_bytes—
> empty_space—
> firmware1.57—
> empty_space—
> some_bytes—
> empty_space]
> 
> [eeprom1.45—
> eeprom1.45–
> firmware1.57—
> empty_space–
> some_bytes—
> empty_space—
> firmware1.57—
> empty_space—
> some_bytes—
> empty_space]
> 
> [eeprom1.57—
> eeprom1.45–
> firmware1.45—
> empty_space—
> some_bytes—
> empty_space—
> firmware1.57—
> empty_space—
> some_bytes—
> empty_space]
> 
> [eeprom1.45—
> eeprom1.45---
> empty_space—
> firmware1.57—
> empty_space—
> some_bytes—
> empty_space]
> 
> (!) Finally I saw in latest dump:
> [eeprom.1.45—
> eeprom1.45–
> firmware1.45—
> empty_space–
> some_bytes—
> empty_space—
> firmware1.45—
> empty_space—
> some_bytes—
> empty_space]
> 
> Eee? What the hell? Why the main unit after reboot*
> 
> *(the most important in reboots when playing with Intel’s NIC is unplugging a cord from PSU or turn it completely off with button OFF/ON on the PSU for a few seconds. Of course it depends of the components - some PSU are able to hold the energy in capacitors for the longer time. Especially if there is only the mainboard without any add-in card (GPU from CPU). It is not strange to have a power indicator diode on the mainboard turned on for a half a minute. To apply changes in the Intel’s NIC, you have to wait till such the diode turns off [try to power on your PC - fans will move a little and the energy in the circuit should be gone  ].)
> 
> did’t erase the second firmware? (The main unit was removing all unnecessary data after the reboot) All other values on the memory flash was the same like in my backup. I thought that eeprom contains all needed adresses. But I was wrong. Or I hit the next bug...
> 
> I probably tried all combinations of my ideas but I couldnt find the way to get rid of doubled firmware. Lanconf was showing that the flash chip is divided into ‘2 partitions’… whatever it means. I was not able to change their settings by any option or prepared dumps. IMO those ‘partitions’ was for 90% the reason of that mess.
> 
> I don’t remember exact values but it is not important now.
> When lanconf analysed my backup file, it shows
> 
> part 0KB (0x0 - 0x2000) 
> part 480KB (0x2000 - ...)
> 
> The doubled firmware gives:
> 
> part 480KB (0x2000 - ...)
> part 480KB (0x7D000 - ...)
> 
> So as a real man, I took a hammer and unsolder the flash memory chip. External dump was the same as the internal one.
> 
> I don’t know why I did it at night. I was so sleepy. I unsoldered it by a hot air but didn’t even looked at the temp. Next day when I gently read the chip. Next I wanted to write my backup to it but then 6 legs out of 8 felt down. They were so fragile… and yes… Temperature. Please do not comment that. Gods will. I ordered the same chips, the old one went to the electric waste. 3 days later I got the new chips at home. I flashed my backup, checked it in few apps. One app when recognized that chip, but shows two tabs. One app out of 7. (?) Chinese sh*t I thought.
> 
> 5 minutes before soldering it, I opened the datasheet. Everything seemed to be OK. Last time I wanted to check voltages to be sure.
> 
> And suddenly. On the same page. Almost the first sentence. 16Mbit nor flash memory with 512 bits of OTP…
> Now I don’t know what to do. Because of the temperature, pads probably can survive one last soldering, so I would rather be sure soldering the chip.
> 
> 64 bytes. 64 hex numbers.
> Maybe that area is empty?
> Maybe it is especially made for i225-V?
> Maybe it is made for specific model of the mainboard or manufacturer?
> 
> This is my ask for you. If someone know what should be in that area, or have a full dump, please write to me. I will pay as much as you want. Software dump can be also helpful to check my 1.45 backup if it has the same structure.
> 
> Maybe someone saw values or can check in the other Gigabyte z490 mainboard? And somehow it would be possible to guess the correct values for my MB. Or maybe someone has an access to damaged Gigabyte mainboard with that NIC card?
> 
> Two things that bother me. On all other mainboards there are memory chips with small additional OTP areas for i225-V… Low chances to just without any reason.
> And the second: that area can be read only by an external programmer I think. I met some people who want to help but unsoldering the chip was above their abilities and the will.
> 
> In that one app which showed me the second tab for OTP memory (and have to find it if offers to write OTP as simply as the standard data), the area of OTP was in a range 0x200000 - 0x200039.
> That memory chip is MX25L1606E.
> 
> Thank you if you read that story. If someone can help me, the cost plays no matter.
> 
> I know that there is a second ethernet card on my mainboard. But it became my master goal. And I am sorry for mistakes.
> 
> PS. You don’t believe how simple I could fix that. I will write it, maybe someone has the same problem or someone’s card stopped to appear after the standard firmware flashing procedure.
> 
> There is possibility to make a short circuit on the pins of the memory flash chip (but don’t forget to measure the voltage and current before and read the datasheet. Check if you can do it without risk of burning the chip. If not, just unsolder one leg (vcc)). When the main i225-v chip doesn’t see the flash memory chip then it appears in UEFI and OS with changed VID to 15FD and the name “i225-V without NVM image”. If you unsoldered the pin, now solder it. If you made short circuit then 1 second after turning on PC just stop. Now you can use every Intel program. The card will be visible for all of them. I suggest to make backup first and see what happened. If you have a backup, just flash it. If on the chip there is untouched eeprom, you can just execute the firmware updater (only remove from the script the line that check current version).
> 
> So it looks like that i225-V cant be bricked by flashing firmware. With the bad firmware, the card disappear from your PC. But it is fully operative (for fixing) after not detecting the flash memory chip during the start.
> The same situation is when you put the empty memory chip. NIC starts in “factory mode” and waits for a flashing command. Good luck.
> 
> Best Wishes

I use a mobile phone for writing… I hope it would be readable…

What did I notice on your screenshots?
Your ‘SPI BIOS chip’ has the ID 0xC22018.
It is the MX25L12835E chip… in its datasheet we can see:
SOFTWARE FEATURES
- Flexible individual block protect when OTP WPSEL=1
- Additional 4K bits secured OTP for unique identifier

What that means? It is a similar ‘problem’ like mine with my i225-V NIC card…
I deleted my post because I saw that there are too small people on this forum who could possibly help me.
The FULL SPI BACKUP of my NIC card has 2MB+512bits of size. I didn’t expect any OTP memory in that chip. Also, almost all apps read only 2MB reading all chip’s memory from that chip.
Only one app had a template of the real structure of the chip and showed me a special tab to write OTP memory. I could read that area using that app but when I discovered that, it was too late. My chip was gone. Now I don’t know if to solder a new NIC chip which contains my backup (2MB) or wait till someone will tell me if OTP area is empty or I have to flash some specific data in that area to get my card working. I don’t want to try soldering the chip with the empty OTP area and see if it works. There are two reasons. First - solder pads are too weak that I have one chance only. In other case, I am 99% sure that I will have to repair 8 pads and tracks to them. Pads are connected directly to smd resistors smaller than my solder tip so I really want to avoid that. Second - I really believe it is not empty + I have the second NIC.

Returning to your chip. It has 4Kb of OTP memory… So your FULL SPI BACKUP has 16384KB+4Kb_OTP=131072Kb+4Kb_OTP=131076Kb.
Your chip has ~16.0004883MB, not 16MB…

I am almost totally sure that i225-V OTP area and your chip’s OTP area are not empty.

All I need now is the knowledge what will happen when I will buy a brand new chip and flash ‘full SPI backup’ without writing OTP area. Will our motherboards turn on?

What is on those OTP areas of Intel products which begin to be equipped with memory chips with OTP areas?
Is that the protection which doesn’t allow to replace the chip to another MB. To treat damaged MBs as donors?

I will probably check that in next weeks. Now I am isolated from any PC. I am writting a lot of text in the small window of my mobile phone.

For now let’s enjoy Christmas.

BUT
Look that we started to talk about something else. I asked if nowadays MBs have on the second BIOS chip 1:1 copy of the first chip or, like in the past, only the MAIN CHIP contains DMI data and the second chip was only the memory for one of the old BIOS version file without DMI data.
On my ‘quite new’ z490 MB, there is only one chip. So it is the same situation like 15 years ago. Only change is the lack of the second chip. This lack is replaced by manually copying the BIOS file on the pendrive and click Q-Flash button. The file on pendrive will NOT be the ‘full SPI copy’ but only the BIOS file from the manufacturers website. In the past the second chip was only the memory place for the BIOS file. Now the pendrive is that memory instead.

IMO the nowadays MBs with 2 chips also have the DMI data only on the MAIN chip and the second chip is only 'the pendrive".

People think: oh… I have the BIOS copy or USB method so whatever I flash on main chip I am totally save. I THINK that is bul***t. I claim that writting wrong data on some areas of the MAIN chip (DMI data) cannot be reversed by the second chip/USB recovery methods.

Till today, I would say that the only ‘real’ recovery is having ‘SPI’ dump. But I noticed now that BIOS chips contain OTP memory.

For me it is the explanation why the simply tool like FPT can access whole chip. It is just another bait from this moneymakers from Intel. FPT cannot read OTP memory. For sure manufacturers wont be using expensive OTP chips without the reason.
Since the morning I claim that FPT gives users only the false belief that they are fully saved because they have SPI full dump. But when the chip will stop working, the brand new chip with ‘that whole SPI backup’ flashed on it, wont fix the MB because of that OTP area. Only having the backup of the OTP area and the external flasher to write it, will work. When there wont be possible to recover OTP data, the only way may be use the chip from the other MB what is also not sure. Monymakers could block this possibility. Then you will be forced to buy the new MB. Of course with Intel chipset and parts. It is almost sure when you have Intel processor. And this is the smart way to make big money.

Remember that this is only my opinion and I can be wrong. When it will be possible, I would check that as much as my abilities allow me.

Best Wishes and Merry Christmas :snowman_with_snow:

1 Like

thanks brother for information about OTP Area or One time Programming ,i first hear about that, it like deep part in manufacture process and written at once and cannot be changed
based on this https://semiengineering.com/knowledge_centers/memory/one-time-programmable-memory/

While the memory contents for a ROM are set at design/manufacturing time, Programmable Read Only memories (PROM) and more recently One-Time Programmable (OTP) devices can be programmed after manufacturing making them a lot more flexible. Once programmed, or blown, the contents cannot be changed and the contents are retained after power is removed.

but found this pdf it possible with CYW4390X: OTP Programming and Using Secure Boot and Secure Flash


read here https://www.infineon.com/dgdl/Infineon-AN214842_CYW4390X_OTP_Programming_and_Using_Secure_Boot_and_Secure_Flash-ApplicationNotes-v03_00-EN.pdf?fileId=8ac78c8c7cdc391c017d0d2825596315

and here from texas aboutt otp
https://www.ti.com/lit/an/spracn1/spracn1.pdf?ts=1671764964343&ref_url=http%253A%252F%252Fti.com%252Fproduct%252FTMS320F280041C

Update : after read your IC I225v you mention brother, it Only INTEL ethernet controler chip
https://www.intel.com/content/www/us/en/products/sku/184676/intel-ethernet-controller-i225v/specifications.html

Conclusion: so i think your best bet using fpt first, and if you already remove your gbe, you can find a way to flash fake mac like that

here more talk about corrupt GBE area
https://hardforum.com/threads/tools-to-flash-and-recover-bios-on-asus-p8xxx-boards-fd44editor-ftk.1726429/

Thank you rofikkernel for your answers. I wish to be able to write in English so quick as in my national language. And without those embarrassing mistakes. After Christmas I will be writting messages from my PC so it could be easier.

I admire your willingness to acquire new knowledge and sharing the information you find.

I have some knowledge about all those electronic parts. Actually I spent 7 years at the university at advanced electronics.
Yes, there are many different types of OTP memory. Its evolution for security purposes has made it incalculable how many versions and capabilities have been designed and implemented. It worries me a bit that I see more and more of it in computers and their components.

.
.
.

Little offropic:
Of course, I don’t mind using a new type of security for certain purposes.
But I don’t understand why they are starting to be used in computers on this scale. 20-30 years ago, the same thing started to happen with mobile phones.
At that time, as now on this forum, a group of people had fun modifying the software of these mobile phones. For ordinary users, it was enough to change the graphics or add the option to save more received text messages.
The more advanced group of people found a way to bypass the ‘hard OTP’ (which included the IMEI) and gain the access to the GSM modem directly. The lack of security from the operators side made it possible to use functions that can now only be seen in movies.
If anyone is interested in this topic, then can read about the possibilities of the GSM system that were originally implemented.
Current mobile phone’s GSM modems have maybe 30% of the original functionality.
But some functionalities still exist, such as the ability to change the content of an SMS received and read by the recipient. A few hours later you can change the content to whatever you want. You just need to have an older phone. Even some with early versions of Android will allow it.
For me those past times were some kind of freedom and I really enjoyed creating some mods. I hope that our MBs will be always open for our ideas.

.
.
.

Thanks rofikkernel for these links. But I have to make it clear why I created this topic.

I don’t have any problems with any ‘SPI’ area. I don’t need any help with the lock flags, etc.
I said about that OTP area because a lot of people don’t even know what it is. And what is worse - nowadays MBs started to have ‘SPI BIOS’ on the OTP chips. And I didn’t see any discussion of this anywhere, and why the chip selection was changed for more expensive ones.

My question is simple. Have anybody tried or know someone/any service center who/that tried to make the SPI dump (without OTP area) and write it to the exactly the same brand new chip and the mainboard started? Or there is a need to copy the OTP area also to run the mainboard.

Apart from that, I would like to know what data this area contains.

Finally, I would also like to know if the possible content of this OTP area depends on the model of the motherboard or on the manufacturer.

.
.

What about my NIC i225-v? It certainly has nothing to do with the GBE region. This card has its own chip which contains firmware, eeprom and MAC address. Using special programs eeupdate and lanconf I have access to this chip and I can even manually change the Mac address.
lanconf
*image from Google

My second NIC may have a MAC address stored in that GBE area because the above tools are not getting proper access to its firmware, etc.

All that means:
The i225-v card is treated by these tools as the Intel card connected to one of the PCIE ports.
The second one is treated as the integrated NIC.

I also mentioned that this i225-V card chip also contains the OTP area and without knowing it I threw away the original chip. I bought a new one and flashed my backup on it but then I noticed that I still have the option of adding 512 bits of the OTP area that I didn’t read ealier. I asked if anyone knows what is in this area because I fu**ed up. I should have read the datasheet before… even before making a dump. If the chip would be 1.8V I’ll probably get some wrong values or damage the chip.

Merry Christmas

thanks brother for sharing with us more deep about hardware level of bios works, after read you searching what inside of that OTP area, i found some interesting about what inside that area
image

Virtually all SoCs require one-time programmable (OTP) memory. Each SoC is different, of course, but two main uses are large memories for holding boot and programming code and small memories for holding encryption keys and trimming parameters, such as radio tuning information and so on.

There are alternatives to putting an OTP on-chip. The data can be held off-chip in some sort of programmable memory (or, perhaps, ROM). But this obviously has the disadvantage of requiring the cost of an extra chip. In smartphones it is not just the cost of another chip that is a problem, but the additional volume taken up by two chips. There is just not a lot of room inside a smartphone to fit everything.

Another alternative to OTP memory is flash memory. This has a big advantage, which is that a flash memory can be reprogrammed many times. However, this comes with a big disadvantage in terms of added process complexity and, thus, the cost of the silicon. Even when off-chip flash memory already exists, security reasons may make using it for holding critical data impractical and running code out of flash memory may, in fact, require data from the flash to be copied to SRAM on the chip, which is both an added cost and yet another increase of unwanted power.

OTP memory has the advantage that code can be executed in-place and does not need to be copied from external memory into on-chip SRAM. It is fast enough and with low enough power as to make copying data out to SRAM something that is unnecessary.
image
The Sidense one-transistor OTP (1T-OTP) architecture is especially area efficient since it uses a single transistor per bit cell. Furthermore, it does not depend on charge storage and so once programmed, it cannot be un-programmed by environmental or electrical upsets. The patented Sidense 1T-Fuse™ antifuse technology works by permanently rupturing the gate-oxide under the bit-cell’s storage transistor in a controlled fashion, obviously something irreversible.

Another big advantage of the Sidense antifuse approach is that it uses an unmodified digital process. No additional masks or process steps are required, so nothing is added to the wafer manufacturing cost. The per-chip cost rises due to the area occupied by the OTP, but since the 1T-OTP macros are very area-efficient this increase is usually very small. Additionally if the 1T-OTP is programmed at the tester, the increase in test time will also result in some extra cost.

The Sidense 1T-OTP memory uses a low read voltage, which further keeps the power of the memory down. The Sidense memory does require some non-standard voltages internally, especially during programming, but these are created using embedded charge pumps and are hidden from the user. The OTP memory can simply be hooked up to the chip’s power supply network just like any other memory block.

Another option to the Sidense solution to lower the power even more is to use differential bit storage. This technique requires each bit of information to be represented using two transistors: one 0 and one 1. This makes sensing the state simpler and as a result the voltage required for the memory can be lower still, along with the associated power. Obviously this comes at the cost of an increase in area since the number of transistors required to represent a given amount of data is doubled within the memory macro.

source:https://semiwiki.com/ip/2784-using-otp-memories-to-keep-soc-power-down/

some science detail about otp https://www.st.com/resource/en/application_note/cd00003983-selecting-between-rom-fastrom-and-otp-for-a-microcontroller-stmicroelectronics.pdf

update:
programmer like this have OTP writer https://www.aliexpress.com/item/32838450146.html

some How to read One Time Programmable (OTP) memory in nRF9160? - Nordic Q&A - Nordic DevZone - Nordic DevZone