Complete the hive registry + binfs on the s3c2440a Platform

This article uses the s3c2440a platform as an example to describe how to use the hive registry in the binfs image to maintain registry data. 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 you can use/binfs/device.exe (/binfs is a hypothetical installation package to invoke it. If the binfs is not successfully completed at this time, 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, so the Registry changes you make are also made in the memory, at this time, if you use flushregister to save the values in the memory to the disk, these changes will still be lost. Two methods to avoid loss. One is to call flushregister and set a flag so that wince will automatically flush after each registry 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" = "Documents and Settings // system. HV"; system. HV is saved to/HDD/Documents and Settings/system. HV.
"Profiledir" = "Documents and Settings"; user. HV is saved to/HDD/Documents 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 flush to system. HV 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.

 

Source: http://blog.csdn.net/fredzeng