The FTW (Fault Tolerant Write) protocol is called when the variable reclaiming happens. Why does Variable driver use FTW during reclaiming? How does FTW work?
We know that variables are stored in ROM. When a variable is updated by SetVariable() calling, Variable driver appends a new variable in the tail and marks the old variable as invalid. Why not to update variable directly? The reason is the hardware characters of flash part. In Write operation, the bit in flash part can be changed from 1 to 0, but cannot be changed from 0 to 1. Erase operation is to erase a block in flash part with FF value. That is why the Variable driver needs to reclaim when the variable store is about full. Reclaiming means deleting invalid variables and combined all valid variables together. The simple reclaiming process is:
- Put all valid variables into memory.
- Erase variable store in ROM.
- Write all variables from memory to ROM.
There is a risk that if the platform is shut down unexpectedly in the step 3, the variables reclaiming are not completed to make platform crashed. To avoid the risk, the reclaiming process is updated as follows, I guess.
- Put all valid variables into memory.
- Set a flag to announce that the reclaiming start.
- Write all valid variables from memory to backup region in ROM
- Erase variable store in ROM.
- Write all variables from memory to variable store in ROM.
- Update the flag to indicate that the reclaiming is completed.
So if the platform is shut down unexpectedly in step 5 and the platform restarts, Don't worry. The platform will recover variables from backup region because it detects the reclaiming has not been completed. The recovery process is:
- Detect the flag that the reclaiming has not be completed yet.
- Restore variables from backup region to variable store.
- Update the flag to indicate that the reclaiming is completed.
Again, if the platform is shut down unexpectedly in step 2, the recovery steps are run again when the platform starts.
How does FTW support this idea? Variable driver uses FTW->Write() to write large data to implement step 2 - step 6 in reclaiming process.
- The flag is updated in NV_FTW_WORKING.
- The backup region is in NV_FTW_SPARE.
We can use a tool to set different variables to trigger variable reclaiming, and use another tool to dump NV_FTW_WORKING and NV_FTW_SPARE. How do we find the two regions? There are many ways to find them.
Method 1 - Dump ROM and search the signature of NV_FTW_WORKING
EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature
#define EDKII_WORKING_BLOCK_SIGNATURE_GUID \
{0x9e58292b, 0x7c68, 0x497d, {0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95} }
Method 2 - Find the values of NV_FTW_WORKING and NV_FTW_SPARE in AutoGenFlashMap.h
The AutoGenFlashMap.h is generated by EDKII build system. We can find the values that we are interested.
#define _PCD_VALUE_PcdFlashNvStorageVariableBase 0xFFF90000U
#define _PCD_VALUE_PcdFlashNvStorageVariableSize 0x0001D000U
#define _PCD_VALUE_PcdFlashNvStorageFtwWorkingBase 0xFFFAE000U
#define _PCD_VALUE_PcdFlashNvStorageFtwWorkingSize 0x00002000U
#define _PCD_VALUE_PcdFlashNvStorageFtwSpareBase 0xFFFB0000U
#define _PCD_VALUE_PcdFlashNvStorageFtwSpareSize 0x00020000U
From the definitions, we know that the offset of FtwWorkingBase (NV_FTW_WORKING) is FFFAE000h - FFF90000 = 1E000h
Furthermore, we can use a tool to dump the content in UEFI Shell. For example,
ToolA.efi -read -id 3 -lba 1 offset e000 -size 70
The tool consumes Firmware Volume Block protocols to dump data from ROM. I will describe it in another page.
Because the page is too long, please refer the page to observe the detail of reclaiming process.
http://countchu.blogspot.tw/2014/10/observe-reclaiming-process-of-edkii.html
I hope this page and the referred page provide you enough background knowledge of FTW and Variable reclaiming process.
