Wince6.0 + s3c2451 FMD-based BSP port-issue of generating eboot. Bin and precautions for Ram entry in Boot. bib

 

1. Generate eboot. bin. The length parsed during download is 0.

Although the eboot content in the BSP package of the original PM architecture is gradually transplanted to the BSP package of the FMD architecture, eboot. the bin is getting bigger and bigger, and later it is sent to a download and cannot download eboot. bin, eboot is downloading eboot. the length parsed in Bin is 0x00000000, but at this time I see eboot. the bin size is 271kb. How can it be 0? Let's take a look at some definitions in eboot \ Boot. bib:

Memory

; Name start Size Type

;---------------------------

ARGs 80020800 00000800 Reserved

Ram 80021000 ipvb000 Ram

Stack 8002c000 2017a000 Reserved

Eboot 80038000 00080000 ramimage

Binfs 800c00000 00021000 Reserved

...........................

Why does the above phenomenon occur when the size of the generated eboot. Bin changes? Later I found that

Ram 80021000 ipvb000 Ram

This problem is solved when the size of 0x0000b000 is increased. This change to eboot. Bin is to include the header file of the charging indicator logo, such as # include added in eboot \ main. C.
"Battery1.h", while some content in battery1.h is as follows:

Figure 1

That is to say, the above situation occurs after the unsigned Global Array battery1 [36608] is added. Use viewbin-r eboot. bin to check the record information of the eboot. bin that can be downloaded normally.

Viewbin... eboot. Bin

Image start = 0x80038000, length = 0x00042948

Record [0]: Start = 0x80038000, length = 0x00000004, chksum = 0x00000288

Record [1]: Start = 0x80038040, length = 0x00000008, chksum = 0x00000260

Record [2]: Start = 0x80038048, length = 0x00000004, chksum = 0x0000004d

Record [3]: Start = 0x80039000, length = 0x0003fff8, chksum = 0x01f90406

Record [4]: Start = 0x80079000, length = 0x00000930, chksum = 0x000240a1

Record [5]: Start = 0x80079930, length = 0x00000054, chksum = 0x00000c10

Record [6]: Start = 0x80079984, length = 0x00000030, chksum = 0x00000ec8

Record [7]: Start = 0x8007a000, length = 0x00000948, chksum = 0x00010a81

Record [8]: Start = 0x00000000, length = 0x800623e0, chksum = 0x00000000

(3)

Checking record #5 for potential TOC (romoffset = 0x00000000)

Found ptoc = 0x80079930

Romoffset = 0x00000000

Done.

The record information of the eboot. BIN file that cannot be downloaded is as follows:

Viewbin... eboot. Bin

Image start = 0x80038000, length = 0x00000000

Record [0]: Start = 0x80079984, length = 0x00000020, chksum = 0x00000b5e

Record [1]: Start = 0x80039000, length = 0x0003ffa8, chksum = 0x01f92096

Record [2]: Start = 0x8007a000, length = 0x00002ed0, chksum = 0x00020a26

Record [3]: Start = 0x80079000, length = 0x000008c0, chksum = 0x00023918

Record [4]: Start = 0x80078fa8, length = 0x00000048, chksum = 0x00000ca1

Record [5]: Start = 0x800798c0, length = 0x00000070, chksum = 0x000007b9

Record [6]: Start = 0x80078ff0, length = 0x00000008, chksum = 0x00000249

Record [7]: Start = 0x80038040, length = 0x00000008, chksum = 0x00000260

Record [8]: Start = 0x80038048, length = 0x00000004, chksum = 0x0000004d

Record [9]: Start = 0x800799a4, length = 0x00000010, chksum = 0x000003d4

Done.

After careful comparison, we can find the following differences:

(1) The length of the record eboot. Bin is changed from 0x00042948 to 0x00000000, which causes the download to fail when eboot. Bin is downloaded.

(2) The start low-fat start of record [0] is changed from 0x80038000 to 0x80079984.

(3) The undownloadable eboot. Bin does not output the starting address of eboot. Bin running in the memory, for example, start address = 0x800623e0.

If you want to thoroughly understand this question, let's study the source code of romimage.exe. Here, we only focus on why the size of Ram 80021000 memory b000 Ram is increased to solve this problem. So let's take a look at the meaning of this item.

 

2. Significance of RAM in Boot. bib

Memory

; Name start Size Type

;---------------------------

.....................

Ram 80021000 ipvb000 Ram

..................

Boot. in bib, memory specifies the allocation of valid and available memory in the eboot image, and the attribute type named Ram above is Ram, romimage determines the purpose of the memory segment based on the type of these memory segments. The above indicates that the starting address is 0x80021000, the memory size is 0x0000b000, which is the ram space that can be used to allocate space when running the eboot image. the description"
Ram entry tells the ROM image tool (romimage.exe) to place any executables, modules, data files, and compressed sections in this folder itself, then for eboot. Bin, It is compressed
The segments (compressed part) are stored in this memory area, and the global data battery1 shown in Figure 1 is the data part that can be compressed, this should explain why adding the header file to compile the array will cause the above problem.

In addition, you must note that the ram-entry memory must be physically contiguous, which has no direct relationship with several pieces of SDRAM on our board, the most important thing is to look at the hardware design and the allocation of the corresponding processor's RAM address. We use s3c2451, so let's first look at this processor memory.
Description of Map

Figure 2

From the memory ing diagram, we can see that s3c2451 supports two banks, and each bank has a maximum address space of 128 MB. Next, let's look at the hardware schematic design:

Figure 3

Figure 3 shows the connection between the signal selection pin of the s3c24s0 chip of the s3c2451 processor and the part of the first chip in the DDR2 SDRAM memory chip

Figure 4

Figure 4 shows the connection between the signal selection pin of the s3c24s1 chip of the s3c2451 processor and the part of the second chip in the DDR2 SDRAM memory chip.

Figure 2, Figure 3, and figure 4 show that the first part is mapped to the 64 MB memory area of the s3c2451 physical memory address 0x30000000 to 0x33ffffff, the second part is mapped to the 64 MB memory area from the physical memory address 0x38000000 to 0x3bffffff, this design determines our physical address-to-virtual address ing table g_oaladdresstable's ing to the memory area as follows:

DCD 0x80000000, 0x30000000, 64; 64 mb dram Bank 6

DCD 0x84000000, 0x38000000, 64; 64 mb dram bank 7

That is, the virtual address 0x80000000 ~ 0x83ffffff ing to physical address 0x30000000 ~ 0x33ffffff, while 0x84000000 ~ 0x87ffffff maps to the physical address 0x38000000 ~ 0x3bffffff, so we can see that the 128ing between the MB virtual memory and the physical memory is as follows;

Figure 5

Now let's look back at the value of the ram entry in Boot. bib.

Ram 80021000 ipvb000 Ram

We can see that 0x80021000 ~ 0x8002c000 physical memory 0x30021000 ~ 0x3002c000 falls into the address space of the first memory chip. Let's take a look at the ram entry value in config. bib.

Ram 80500000 03400000 Ram

It can also be seen that it falls into the address space of the first memory chip, and the memory area where the ram item is located meets the requirements of physical address continuity.