Implementation of hive registry + binfs on the s3c2440a Platform

Implementation of hive registry + binfs on the s3c2440a platform | flash partition and checksum in WinCE

Implementation of hive registry + binfs on the s3c2440a Platform

Today we will summarize some implementation processes and principles.
My example is based on Samsung s3c2440a + Samsung onenand + wince5.0. the development platform is platform Builder 5.0. First, we can run Images Based on Ram register normally, in addition to storing images, flash provides users with file systems. These drivers use Samsung's pocetstoreii15.
Let's take a look at the underlying stuff. Our image mainly consists of two parts: xipkernel. Bin and NK. Bin. Xipkernel. bin contains some programs and DLL files that are core and frequently loaded in wince. These files will be copied to ram by the boot loader at startup, in this way, you can use the xip (excute in place) in Ram. Hosts can also be stored here. These files are copied to the memory for execution only when necessary, saving the memory and accelerating the startup time. Hey, here we will probably know the working principle and importance of binfs.
Binfs is built using Ut (an underlying tool set of the OEM, ut automatically saves the xipkernel and NK to the specific logical sector of flash when the image is burned. at startup, the boot handler is in NK. in bin, then we can use \ binfs \ device.exe (\ binfs is a hypothetical installation package to tune it up. If this time binfs is not successfully completed, device.exe cannot be executed, then the system will surely fail.
Now let's talk about hive. In fact, hive is a very simple thing. It's strange that the binfs and hive have brought together many problems in the wrong direction. We could have done the results for four or five days in one day, nnd. In this case, there are two types of registries, Ram-based and hive-based. The former is used by default. If the former is used, Pb will compile the common. reg and platform. reg is called reginit. INI files are then compressed to default. * ** put the file in xipkernel (if the extension is forgotten, there are old signs). When the image is up, it will decompress the file into RAM to form a ram-based registry, since it is Ram-based, all changes will evaporate after power failure, haha. What should we do? Actually, you can think of it again. Isn't it enough to save it to the disk !? It's too clever for you, but if you want to put the entire registry on a disk (sdmmc, HDD, or flash), how does wince read the Registry without loading the drive of your disk? In general, the driver for loading the disk also requires registry support!

Hey, by the way, this is what hive thought of. It depends on how it is done. It divides the Registry into two parts (in fact, three parts. At that time, there were two steps to divide the user. HV and system. the first part is boot. the HV registry contains some settings required for booting before obtaining the Registry saved on the disk. The Registry and ram-based are the same, after the change, the power is lost, so the registry keys in this part do not need to be changed. All the changes need to be placed in the second part, and the second part is system. HV and user. HV, that is, the Registry to be put on the disk. during compilation, Pb will be based on platform. reg and common. the label in Reg determines which table items are put in Boot. in HV, this label is; hive boot section; end boot section, which inserts the table item Pb between the labels into Boot during compilation. remove (boot. HV is a binary file. It depends on the tables in it. In NK. Bin, binfs must be available in the first stage. Otherwise, it is impossible to create conditions for system. HV. When wince is started for the first time, there is no Dongdong on the disk. At this time, WinCE will default the memory. HV and user. copy HV to the location specified by bootvars in the registry, default. HV is often renamed to system. for the second startup, check whether the HV on the disk is consistent with that in the memory. If they are inconsistent, load the table items on the disk.
The whole process is like this, but note that the hive Registry is also running in the memory. The difference is that the modified table items will be read from the disk at startup, this ensures the speed. Therefore, the Registry changes you make are also made in the memory. If you do not save the values in the memory to the disk, these changes will still be lost. Two methods to avoid loss. One is to call the regflushkey function through an application, and the other is to set registryflags registration key value to 1 in the registry, let the system automatically save the registry after each change.

Finally, let's summarize what I have done:
1) Pull hivebased registers to the workspaces of the project in Pb.
2) Add the following list items in platform. reg to boot. HV.
3) build image
Attach my registry settings for reference:
; Timeout ;-----------------------------------------------------------------------------------------
; All these entries below will be add to boot. HV when hive register is enabled!
; Hive boot section
[HKEY_LOCAL_MACHINE \ init \ bootvars]
"Systemhive" = "events and Settings \ System. HV"; system. HV is saved to \ HDD \ Documents ents and Settings \ system. HV.
"Profiledir" = "Documents and Settings"; user. HV is saved to \ HDD \ Documents ents and Settings \ Default \ User. HV.
"Flags" = DWORD: 3; this should be the table item in which device.exe is started under wince 5.0.
"Defaultuser" = "default"; we only have one user default, which basically decides the path of user. HV.
"Registryflags" = DWORD: 1; this is to set the Registry to automatically refresh to system. HV in flash after each change.
; ========================================================== ======================================
This part is the binfs registry key. If you are not using binfs, you do not need to drag them to boot. HV.

[HKEY_LOCAL_MACHINE \ SYSTEM \ storagemanager \ autoload \ smflash]
"Driverpath" = "Drivers \ blockdevice \ smflash"
"Loadflags" = DWORD: 1
"Mountflags" = DWORD: 11
"Bootphase" = DWORD: 0
"Flags" = DWORD: 1000

[HKEY_LOCAL_MACHINE \ drivers \ blockdevice \ smflash]
"Prefix" = "DSK"
"DLL" = "bibdrv. dll"; the binfs driver dll must be inside the xipkernel.
"Order" = DWORD: 0
"IOCTL" = DWORD: 4
"Profile" = "smflash"
"Friendlyname" = "Samsung Flash Driver"
"Mountflags" = DWORD: 11
"Bootphase" = DWORD: 0
"Flags" = DWORD: 1000
; Bind binfs to the block driver

[HKEY_LOCAL_MACHINE \ SYSTEM \ storagemanager \ profiles \ smflash]
"Defaultfilesystem" = "binfs"; binfs path:/binfs
"Partitiondriver" = "mspart. dll"; the driver DLL of this partition must be inside the xipkernel.
"Automount" = DWORD: 1
"Autopart" = DWORD: 1
"Mountflags" = DWORD: 11
"Folder" = "residentflash"
"Name" = "Samsung flash disk"
"Bootphase" = DWORD: 0; binfs must be loaded in the first phase.
"Flags" = DWORD: 1000
"Mounthidden" = DWORD: 0; with this, you can see all the NKS of NK. bin in the/binfs directory.
; ========================================================== ======================================
; This part is the driver for setting the disk to save system. HV. Everyone is different, but it is similar.
Here I am using the Flash Driver poketstroeii15, and system. HV is stored in the first flash partition.

If bsp_pocketstore
[HKEY_LOCAL_MACHINE \ drivers \ builtin \ pocketstore]
"Prefix" = "DSK"
"DLL" = "ondisk. dll"; this is loaded after binfs, so it can be placed in NK. Bin.
"Order" = DWORD: 1
"Profile" = "pocketstore"
"Iclass" = multi_sz: "{A4E7EDDA-E575-4252-9D6B-4195D48BB865 }"
"Bmlvolumeid" = DWORD: 0; BML volume id = 0
"Bmlpartitionid" = DWORD: 8; BML parition id = partition_id_filesystem
"Index" = DWORD: 2
"Flags" = DWORD: 1000; this flag specifies that the driver is loaded only once in Boot. HV.

[HKEY_LOCAL_MACHINE \ SYSTEM \ storagemanager \ profiles \ pocketstore]
"Defaultfilesystem" = "fatfs"
"Partitiondriver" = "mspart. dll"
"Automount" = DWORD: 1
"Autopart" = DWORD: 1
"AutoFormat" = DWORD: 1
"Mountasbootable" = DWORD: 1; this is the key to specifying this partition in wince 5.0 to save system. HV
"Folder" = "HDD"
"Name" = "NAND drive"
"IOCTL" = DWORD: 4
[HKEY_LOCAL_MACHINE \ SYSTEM \ storagemanager \ profiles \ pocketstore \ fatfs]
"Enablecachewarm" = DWORD: 0
Endif
; ========================================================== ======================================
; End hive boot section
Supplement:
My flash is divided into four zones. The first zone is a 4 K bootloader that can only run in the nor mode, and then put ut in the second zone, and xipkernel and binfs in the third zone, the fourth partition is to format all the remaining slices into a FAT partition as the file system. HV is placed in the last partition. After wince, we can see that there is a document and setting folder, and the HV files in it are hidden.
We use Samsung's onenand flash, which is actually a 4 K nor NAND Flash. Our bootloader is also divided into three parts, the first part of bootloader is some jump commands mapped to the 0x00000000 address. This part will be burned into the first 4 K of flash, then Samsung's onenand will automatically copy the first 4 K of data to a physical module similar to nor, which supports direct addressing of the CPU; the second part is IPL, its function is to load the image or UT in the NAND Flash, and then jump to the entry in Its RAM for execution after loading, because the CPU data line and address line can only directly access nor flash at this time, to access NAND Flash, you must have the NAND interface driver, therefore, the IPL part contains the NAND interface-driven code, which leads to dozens to hundreds of KB of IPL code. One of our flash blocks is 128 kb, the first two parts occupy two parts. The third part is ut, which is a common tool, such Image, bootloader, flash formatting, and other commonly used maintenance and image upgrade tools. The data in this part consists of a lot of drivers, which is also very large and looks like kb.
In the end, the three bootloaders occupy the first 10 blocks (blocks) and 128 K * 10 blocks of flash, but these three parts are two BML partitions in Samsung's flash partition (the concept in Samsung's flash drive pocetstoreii, you can think of it as a normal disk partition ), and so on.
Next we will place an MBR in the block, and then we will place the image of Wince from 11 blocks. This zone is the third BML partition, And the size is usually around 40-blocks, because the image of Wince is around 4-20 m, the partitioning work is done by the UT mentioned above. I did not carefully read the source code, but I only saw functions such as bmlformat, the parameters are shown in the following figure. If binfs is used, two modules will be placed in this zone: xipkernel and NK. The NK region will be identified by the binfs driver and loaded into the FAT partition, we can see in the resource manager of Wince that we have not understood how it is identified.
In the end of the big budget estimate, all the space above will be occupied by more than 20 mb. You can use the remaining space at will, the partitioning method still calls bmlformat and stlformat in Samsung's flash drive. After the partition parameters are set, they will automatically create the partitions. This part of the work is done in BT. Then, in wince, you only need to read these partitions and display them as disks. This is similar to the driver of SD and HDD, refer to the above registry syntax between "If bsp_pocketstore.

++ ++

Flash partition and checksum in WinCE

WinCEChecksum is often used to verify the image file to be written into flash, and to check the integrity of the written data, generally, there are two types of images: osimage and UT binfiles.

The principle of checksum is to open a file in binary mode, accumulate the values of all the bytes one by one until the last byte, and finally get an accumulated value, it is the result of the checksum. From the checksum feature, we can see that the bytes whose data value is 0 will not affect the final result. This feature is also a weakness of checksum and cannot be like MD5, sha1 and other digest algorithms can basically reflect even a bit change, but this feature also makes it easy to calculate the integrity of the image data files stored in flash during running of wince.

To get the correct checksum value from flash, you must first understand the image burning mode in flash. This includes understanding how the image file is organized internally, how is the flash partition and block allocation performed.

Take the flash of sumeda as an example to analyze the general principles of Flash partitioning:

Flash partitions of Wince are generally divided into the NAND bootloader (NBL) area, binfs area and file area, NBL area stores Bootloader and tool programs for burning and writing images, and binfs partitions store MBR and image xipkernel. bin, chain. BIN and NK. BIN and other OS data. The file area is usually formatted as a FAT partition to manage disks and partition management programs on the upper layer of wince. The Flash partition is determined by the ut when the image is burned, including the starting and ending block addresses of each partition, the partition size and type. The detail is as follows:

1) The NBL area usually occupies the size of 10 blocks (128 K/block). Although the partition is small, it is the most important part. It stores the three ut modules: nbl1 (bootloader ), nbl2 (IPL, INIT program loader) and nbl3 (upgrade tools) are stored in the first block of flash, flash chips are designed to ensure the reliability of these blocks during production, especially when the first bootloader code and IPL are saved. In terms of experience, the three NBL modules add up to a total of more than 400 k, and most of the 10 blocks occupied by the NBL = K × 10 byte space is free. For the convenience described below, assume that nbl3_end_blcok is the last block number of NBL.

2) binfs partitions are followed by BL partitions, that is, ce_start_block = nbl3_end_blcok + 1. Then, the first partition of binfs is generally stored in MBR. MBR is only a flag here, unlike MBR in PC hard disks, MBR is mainly used to save partition table information and boot code. Therefore, the starting and ending block range for saving OS data in the binfs partition is ce_start_block + 1 to ce_start_block + ce_max_block. In my project, the size of the block is usually about 250, which is about 30 Mbytes, the image size of Wince generally does not exceed this size. If necessary, you can increase the size of the image when partitioning.

3) The file partition in Flash is to simulate the remaining block into a hard disk. Block devices similar to the CF card allow wince to be loaded into a drive letter.

Now let's go back to the question: how to calculate checksum.

1) ut checksum Calculation

The binfile of Ut is bootloader. bin (nbl1), IPL. bin (nbl2) and upgradgatels. bin (nbl3) is a packet generated by these three files, and then the checksum value is calculated using the checksum tool on the PC, our goal is to use the AP after wince to read the three NBL partitions of flash and calculate the value in real time.

The binfile of UT will be completely burned to the block numbered 0 to nbl3_end_blcok of NAND Flash (although it will be divided into three parts, the data is complete ), the number of blocks occupied is determined by the size of the binfile, and the remaining space is filled with 0. Although we do not know the end position of the binfile, we can directly call the NAND Flash Driver after we know the feature of zero in the remaining space, in addition, you can use the Lightweight Block-free driver code to directly read all data from 0 to nbl3_end_blcok, and then accumulate each byte to get the checksum value.

2) IMG checksum Calculation

As we all know, if multixip region is defined, the image of Wince is compiled using romimage to generate multiple binfiles. Here we suppose we have defined two region in the bib file of the image: xipkernel and NK, then the romimage CE is executed. after bib, we will get xipkernel. bin, NK. bin, chain. bin three files, and finally call makebinfs to generate a ceimgb. nb0 image file, we will also use the checksum tool for ceimgb. calculate the complete checksum value of nb0.

There are two differences between the write process and ut: 1) if you select the write content, all the data in the UT binfile will be burned into flash, the IMG image file contains some header information that does not need to be burned in, which may lead to incomplete flash data. 2) the functions used for burning NAND Flash are different, because the position of IMG burned in Flash is in a common block area that is not specially protected, you must consider the management of Bad blocks, therefore, when calling a specific read/write interface, you need to use a higher level of code. Taking the Samsung flash drive poketstoreii as an example, the read/write function used for UT writing is nf_readpage, however, stl_read/write is used to write the IMG image.

The first difference determines that if we want to calculate the correct IMG checksum value, we must not burn it into the ceimgb in flash. the header data of nb0 is burned to the flash memory reserved for IMG and not occupied. For example, the last part of the IMG reserved space is ce_start_block + ce_max_block. By modifying the code for burning IMG, we can burn the data from 0x0 to 0x248 after writing the data of the Three bins of IMG (not clearly remembered, probably) data is written to the ce_start_block + ce_max_block block. In this case, because other free space is filled with 0, we can call stl_read to put the data from ce_start_block + 1 (+ 1 is to skip the MBR block) to ce_start_block + ce_max_block, all data is read and the last checksum value is accumulated.

Http://blog.csdn.net/fredzeng