Use uboot to replace eboot and start WinCE

1. Analysis of Wince Startup Process
I am using the utu2440 Development Board. The Boot files of the Board include nboot1, nboot2, eboot, and wince kernel. The functions of these files are as follows:
Nboot1: S3C2440 for NAND Flash, you can run the code that can load up to 4 K. After nboot1 is started, nboot2 will be loaded from flash.

Nboot2: Read the wince kernel from flash, load eboot, and display the startup screen.

Eboot: Implements partitioning, formatting, and burning the wince kernel image file for flash. Note that eboot will use NK during the process of burning the wince kernel image. decompress bin to Nb. nb0 is written to flash.

Ii. analyze the possibility of uboot starting WinCE
Nboot1 and nboot2 functions can be completely replaced by uboot. uboot itself has enabled NAND falsh, and then the Kernel File nk of wince. nb0 can be directly loaded to the 0x30200000 of the memory, and then run the wince Kernel File directly using the uboot go command.
What is more difficult is the uboot implementation of the eboot function. The eboot partition function creates a binfs partition in flash to store the wince kernel image file. In wince, binfs partitions can be directly supported, you can see the image file. If you want to implement this function in uboot, you must add the flash Partition Function for uboot. In order to test the possibility of implementation, a lot of implementation has been done in two days, it takes too much time and effort to complete this function (if any brother can help ).

After the binfs support is removed, uboot can enable NK. the nb0 program is written to flash, and the 0 X position is read at startup. Finally, use the go command to load and start wince, it should be very simple (it turns out that the idea at this time is too much ......)

Iii. Test possibilities

Use uboot to load NK. nb0 to 0x3020000, and then go 0x30200000. After a while, we can see the wince interface. This step is successful, and the next step is to directly burn it. However, we soon discovered that we could not start uboot after using this method to start wince once. by reading the Flash content, we found that wince formatted the flash block of uboot. Why?

It turns out that this wince kernel has the automatic partition Formatting Function. As mentioned above, partition formatting is not implemented in uboot, so this function must be added in wince. However, in this way, WinCE will format uboot. By reading eboot, we found that eboot will mark the eboot area as bad blocks during formatting, so that wince will not be formatted, it seems that this problem must be solved first.

Iv. Division of Flash Management Areas

My flash size is 64 m, and the wince Kernel File plus uboot cannot exceed 32 m. This defines that the first 32 m of Flash is managed by uboot, which does not exist for wince, the 32m is stored in wince and managed in wince.

If you want to prevent wicne from formatting the first 32 m, you can mark all the first 32 m as bad blocks in uboot. However, in this way, uboot performs Bad Block Detection for all flash operations. If this is done, the bad block mark is removed each time uboot reads and writes data to flash. After the operation is completed, it is marked as a bad block. The idea should be feasible, but it is too troublesome to do so. Of course, we can reverse-think about all the major roads in Rome. Why can't we modify the wince kernel to shield the first 32 M Flash space?

By reading the BSP of wince, we found a very important macro definition.

Loader. h

// NAND boot (loads into steppingstone) @ Block 0 </P> <p> # define nboot_block 0 <br/> # define nboot_block_size 1 <br/> # define nboot_sector block_to_sector (nboot_block) </P> <p> // TOC @ Block 1 </P> <p> # define toc_block 1 <br/> # define toc_block_size 1 <br/> # define toc_sector block_to_sector (toc_block) </P> <p> // eboot @ Block 2 </P> <p> # define eboot_block 2 <br/> # define eboot_sector_size file_to_sector_size (eboot_ram_image_size) <br/> # define eboot_block_size sector_to_block (eboot_sector_size) <br/> # define eboot_sector block_to_sector (eboot_block) </P> <p> // # define reserved_boot_blocks (nboot_block_size + toc_block_size + eboot_block_size)/* this parameter defines the number of preview blocks. The default value is nboot + TOC + eboot, to shield the preceding 32 MB space, I need to modify this definition */</P> <p> # define reserved_boot_blocks sector_to_block (file_to_sector_size (0x2000000 )) </P> <p> // images start after OEM reserved blocks </P> <p> # define image_start_block reserved_boot_blocks <br/> # define image_start_sector block_to_sector (image_start_block) </P> <p>

Modify reserved_boot_blocks and re-compile WinCE (because I use win7 and do not support wince5 compilation, I had to use a virtual machine to compile it. The speed is really too frustrating, resend uboot and download the wince Kernel File NK. nb0, start wince, disappointed, still disappointed, uboot is still erased.

In order to clarify the cause of the problem, open the wince debugging information (http://blog.chinaunix.net/u3/105764/showart_2101341.html), especially all the debugging information of the NAND Flash Driver. Re-compile, download and run. It is found that the location where Windows starts to be erased is correct. I reset the Development Board when the erasure is not complete, and uboot can be started normally. Re-run. After the erasure operation is complete, I reset and find that uboot cannot be started. This is really strange. The location where the erases are started is correct and the block increments each time, how can I erase the previous block? Again, I found the problem. The starting position of Wince's entire erasure is correct, but the block ended is incorrect. The entire flash block is 4096, from the correct starting position, WinCE wiped 4096 blocks. This is probably the reason why uboot was erased.

After reading the FMD driver of wince, I initialize flash here and find that there is a sentence that is hard to understand.

// Pflashinfo-> dwnumblocks = num_blocks;/* this is the original definition and is changed to the following value */</P> <p> pflashinfo-> dwnumblocks = num_blocks-image_start_block; </P> <p>

 

In principle, when initializing the number of Flash blocks, at least two nbot eboot parts should be blocked, but this BSP is not blocked. I checked it online and some BSP is defined
Num_blocks-image_start_block. I think this definition is more reasonable. Maybe it was because BSP was released from Samsung to my hand and has been modified by many people, leaving this bug behind.

Re-compile and load. Everything is normal. wince can be started normally.

Finally, burn the wince Kernel File to flash and load it automatically when uboot starts. Everything works normally.

After this modification, if valid MBR is not detected during wince startup, it will be automatically partitioned and formatted, and will not be formatted during the second restart, the remaining 32 MB space can store user files. In the storage management of wince, we can see that the flash size is 32 MB, and the front 32 m space is indeed blocked.

At this point, the work has come to an end. uboot can burn, write, and load wince normally.