Download stepldr via USB Based on wince6.0 + cloud6410

 

* ****************************** Loongembedded ******* *************************

Author: loongembedded (Kandi)

Time: 2011.7.31

Category: wince bootloader Development

* ****************************** Loongembedded ******* *************************

 

Note: Based on the real6410 Development Board, this article uses the MLC-type NAND Flash k9g8g08. Here we will learn to download the image file block0img. nb0 in the stepldr stage.

 

The image files of the Windows CE operating system and bootloader generated by the Windows CE development tool platform build are mainly in two formats. bin is a record-type image file with the filename suffix and. A raw image file with the suffix nb0. The former organizes image data in units of records, and the latter is a binary snapshot of the image running in an embedded system.

 

The Windows CE image file has a 7-byte signature (magic number) in the start position of the file data. It corresponds to the image file format one by one as follows:

"N000ff \ x0a" -- bl_image_type_manifest

"X000ff \ x0a" -- bl_image_type_multixip

"B000ff \ x0a" -- bl_image_type_bin

"S000ff \ x0a" -- bl_image_type_signed_bin

"R000ff \ x0a" -- bl_image_type_signed_nb0

No signature -- bl_image_type_unknown

Among them, bl_image_type_signed_nb0 represents the format of the original image file. According to the implementation Part Of The downloaderimage function, the security is not required (the macro secure_bootloader is not defined, which is also the default situation ), the downloaderimage function treats the unsigned bl_image_type_unknown type as the original image. However, when the security is high (the macro secure_bootloader is defined), image files without signatures should not be accepted by bootloader.

The method for processing original image files is the easiest. bootloader only needs to read all the image data from the download port and store the data to the corresponding storage location, and does not require verification. The starting address and length of the original image file data in physical storage depend on the manifest data. the nb0 image file cannot be downloaded separately (if the macro secure_bootloader is defined, the downloaderimage function supports downloaderimage as a separate nb0 file .), Bootloader must first download the image file of the bl_image_type_manifest type that serves as its leading property information.

 

The data in the bl_image_type_manifest image file is the region information of the record-type image file with multiple segments. Multi-segment images are, in short, binary data of the operating system or bootloader is scattered in discontinuous physical storage intervals. Manifest literally means a "cargo bill". This type of image file is not real Windows ce OS or Binary Runtime data of bootloader, only the header information used to download multi-region images. Due to the special nature of the image data, "n000ff \ x0a" -- bl_image_type_manifest type image files -- also known as manifest data -- are stored in different locations from general image file data, it uses the special global variable g_downloadmanifest for storing dowloadmanifest.

The dowloadmanifest struct type is defined in the header file \ public \ common \ oak \ Inc \ blcommon. h as follows:

Figure 1

Multi-segment means that data is stored in multiple image files in the binary operating hours of an operating system or bootloader, the data of these image files corresponds to multiple physical storage areas that can be continuous or discontinuous. Dwnumregion, a member of the dowloadmanifest struct, is the number of segments of a multi-region image, that is, the number of files of multiple subsequent image files. The region array member is responsible for storing the information of each region segment. The bl_max_bin_regions header file % _ winceroot % \ public \ common \ oak \ Inc \ blcommon. H is defined as 25, which means that the number of multi-region image segments cannot exceed 25. The element type regioninfo of the region array member is a struct defined in the header file blcommon. h:

See figure 1.

The three members of the regioninfo struct, dwregionstart, dwregionlength, and szfilename, respectively indicate the starting address of an image segment in physical storage, the length of the segment in bytes, and correspond to the Image segment. image File Name.

For image files of the bl_image_type_manifest type, the file data follows the 7-byte format pattern, and the download port reads the 4-byte verification data, followed by the number of 4-byte segments. The number of segments is stored in the dwnumregions Member of the g_downloadermanifest global variable, the attribute data of the g_downloadermanifest.dwnumregions segments of the image is read in sequence, including the starting address, segment length, and the image file name of the segment data, which are stored in the element of the g_downloadermanifest.dwnumregions array. The downloaderimage function calls the checkimagemanifest function to read the 4-byte verification data and all subsequent manifest data. Then, the checkimagemanifest function calls the verifychecksum function to verify the manifest data, however, the verification scope is limited to the data that stores the field header information in the g_downloadermanifest.regions array, excluding the 4-byte g_downloadermanifest.dwnumregions data.

Bl_image_type_manifest is an alternative among all image file formats. It is only used for downloading other types of image files but with leading information, it does not contain valid Binary Runtime data of the Windows CE operating system or bootloader. If the operating system image has only one segment, or you use a record-type image file that contains the storage location and other header information, you can also use the manifest leading data. After the image file of the bl_image_type_manifest type is downloaded, The downloaderimage function does not immediately execute and return the result, download the image file containing the real operating system binary data based on the information provided by the manifest data in the global variable g_downloadermanifest.

The following describes how to download block0img. nb0 Based on the bootloader code. The main part of the main process function bootloadermain for downloadloader is as follows:

Figure 2

The following describes how to download the downloadimage and oemlaunch functions.

1. downloadimage Function

1.1 read the manifest leading data of the image file

Figure 3

1.1.1 getimagetype Function

The downloadimage function first calls getimagetype () to obtain the type of the downloaded image file, which is determined based on the first seven bytes of the image file signature.

Figure 4

1.1.2 oemreaddata Function

We know that we use the oemreaddata function to read the data of the image file. Because we use USB to download data, we call the ubootreaddata function. We will analyze this function below:

Figure 5

1.1.3 The checkimagemanifest function reads packet verification code, regioninfo struct data, and verifies packet verification code.

Figure 6

1.2 read the actual image file data based on the manifest leading data

Figure 7

1.2.1 downloadnb0 Function

The first part of this function,

Figure 8

1) oemmultibinnotify Function

Figure 9

2) oemverifymemory Function

Figure 10

The second part of the downloadnb0 function body:

Figure 11

Here we know the downloaded block0img. nb0 is first cached at the address starting with 0x80100000 in ram, and NK is downloaded. bin is also cached at this address. Figure 5 shows that the image is first downloaded to the address starting from 0x83000000 in Ram, therefore, we can only change 0x83000000-0x80100000 = 0x2f00000, that is, a 47 MB image file. If we want to download a larger image file, we can change it to 0x83000000. Of course, at this time, we should also consider the actual size of RAM (Here we use mobile DDR.

1) oemmapmemaddr Function

Figure 12

If the target system needs to support downloading image files to flash, you must call this function. Because flash operations are slower than Ram operations, read and write operations may even stop when the disk is erased. oemmapmemaddr uses Ram to buffer image files, this function maps the flash Address to the RAM address so that the data written to flash is actually buffered into RAM and then written to flash.

 

1.2.2 computechecksum Function

As shown in figure 7, the computechecksum function is used to calculate the verification code for the image file data.

1.2.3 writeimagetoflash Function

Figure 13

This section describes the downloadimage function. The following describes the oemlaunch function.

 

2. oemlaunch Function

Figure 14

This part mainly writes the image file to flash by calling the writerawimagetobootmedia function.