Uboot-> eboot-> NK. Bin

Original address http://blog.csdn.net/sannik/article/details/8204912

Thank you very much for your good experience! I started to get in touch with uboot and Linux, but I want to use this uboot boot to guide wince, so it is very helpful. Follow the instructions first! Hope it will succeed!

Recently, on the s5pv210 platform, we tried uboot to boot eboot and then loaded the kernel image NK (xip. Bin) from eboot ).

Knowledge reserve: The uboot process starts from power-on to uboot; The uboot process;

With regard to s5pv210 CPU power-on, s5pv210_irom_applicationnote_preliminary_20091126 describes how irom guides bootloader.

According to the startup process described in Samsung s5pv210_um_rev1.1 manual, s5pv210 will execute the solidified startup code from irom, initialize the clock, and judge the Startup Device, and copy BL1 (up to 16 KB) from the boot device to Iram (at 0xd002_0000, where the verification information of BL1 stored in 16 bytes prior to 0xd002_0010 and BL1 size, verify BL1, verify OK and transfer it to BL1 for execution, BL1 continues initialization, and bl2 is copied to Iram for verification, OK and then transferred to bl2; bl2 requires complex initialization, including DRAM initialization. After the initialization, the OS code is copied to DRAM and transferred to the OS for execution and boot.

However, the above Iram only has a size of 96 K, which is definitely not enough for the increasingly complex uboot. Therefore, when using uboot to start boot, it is not all executed according to the instructions in the Samsung manual, the details are as follows:
First, I think bl0, BL1, and bl2:
Bl0: indicates the startup code solidified in the irom of s5pv210;
BL1: Part of uboot code executed in Iram;
Bl2: indicates the complete uboot code executed in the memory;

Refer to http://blog.csdn.net/s5pv210_devboard/article/details/7936405; this is from tiny210. For detailed procedures of s5pv210 platform, refer to uboot source code,

The first phase of the Code to look at/board/Samsung/***/u-boot.lds Text Segment can be known to pull.

Uboot startup process, a lot of online information. I will not go into details here.

====== Start wince6.0

The development experience of Wince is zero. The wince startup process is probably only known. For more information, see smdkv210_wince60_bsp_installationguide.

Stepldr. nb0: The irom is loaded into the SRAM. It mainly initializes hardware and loads eboot. Similar to the uboot bl1.

Eboot. nb0: it will also initialize some; load the OS image, boot image...

Bootimage. nb0: stepldr + eboot

OS iamge: Single-xip multiple-xip. My work is only responsible for guiding eboot, so that eboot can work normally.

Debugging process:

1. wince file: boot. nb0 logo.bmp xip. Bin

Boot. nb0 is the bootimage. nb0 above. I direct eboot, so you need to know the distribution of boot. nb0: 0x32 sector stepldr + 0x400 sector eboot.

The. nb0 file is a data file and can be run directly in the memory.

2. Confirm that uboot and eboot can work independently in their respective system environments.

3. Determine the memory address loaded by the eboot: 0x47700000, the size is 0x8000 (0x400*512), and the physical address.

In uboot download mode, you can use movi read eboot 47700000 8000 to read the memory from the SD/MMC device, or fatload MMC 47700000 eboot, migrate the eboot file from the SD card vfat partition to the memory.

A headache begins. The idea is clear and simple. When I vowed to go 47700000, I found no logs.

The tragedy... various misunderstandings, debugging, and disappointment during the period... are summarized as follows:

1) It takes time to understand the first stage of uboot, especially to compile some code. U-boot.lds initiation, CPU/s5pc11x/start. S->

./Lib_arm/board. C: detailed process of start_armboot. Hardware initialization: I/D cache, MMU, DDR, PLL...

2) learn the debugging methods. Although the conditions are limited, you must learn to create conditions...

First, make sure that the PC Pointer Points to 0x47700000 and the content moved to it is correct.

In the run_command migration command process, the most basic print out the content 0x47700000 after the migration; and compare it with the eboot source data. Without a hardware simulator, you cannot track the values of the PC pointer, CPSR, and other arm registers. You can use the lighting method to control the output tracing code of the gpio port after redirecting to eboot. <What methods can be used in uboot to print the trace and track the PC?>

It is found that the lighting method is ineffective; the serial port is still not printed (anroid, The UART debuger of Wince is the same, and the serial port is also initialized ). This is probably because the environment configuration of uboot and eboot is different. Check it... first, do part of the work. Some ideas and direction http://social.msdn.microsoft.com/Forums/en-US/winembplatdev/thread/4810a3c0-4362-46a8-b57b-80e12ca8ba9d of reference link when doing this work

It is worth mentioning that there are many areas of suspicion during the period (DDR, MMU, PLL, power...) that there is too much possibility of a combination at the time of modification. This kind of "stupid" constantly tries to buy a ticket for lack of experience and technology. This seemingly physical labor behavior has become the best way; every time I see no log, I am disappointed; but I always feel that I am not far from success.

In this way, compare the difference between the Environment configuration of stepldr and uboot in wince bootloader. Later, only the eboot is successfully guided.

Cause:

MMU must be disabled in uboot, although 0x47700000 previously moved is a physical address. In eboot, enable MMU again, and its memory ing is different from that of uboot.

Why? Http://blog.csdn.net/xxblinux/article/details/6281295 saw this can understand some. Even if MMU is enabled, make sure that the physical address mapped to the virtual address is the same as the physical address in 0x47700000 memory!

Block include/configs/smdkv210single_wincalcd_android.h // # define config_enable_mmu

Pay attention to the text_base = 0xc3e00000 file in the Board/Samsung/wicalcd/config. mk file.
0xc indicates that it is a virtual address. If MMU is switched off, change c3e00000 to 23e00000 In The makefile directory at the top level.
Uboot will use this address to compare with the PC register. If it does not match, it will copy the program to the SDRAM. If it matches, it will run the program.

Since it is a dual system, the uboot of MMU must be able to guide the android kernel. I believe that in uboot to enable MMU has no function, in the future kernel will re-Initialize MMU http://celinux.wikidot.com/linuxboot in uboot code will be virtual address corresponding to physical address.

# Define config_bootcommand "movi read kernel c0008000; movi read rootfs 20a00000180000; bootm c0008000 20a00000"

Change c0008000 in to 20008000. Similarly, for the rediscovery mode, change to "fatload MMC 2:1 20008000 zimage" "bootm 20008000"

Eboot boot xip. Bin:

Requirements:

1. wince kernel uses the inand space after the image as the user space and reformatted it as FAT32, so that the Android system cannot be started after the next startup.

2. Android and wince should share the hard-disk partition of inand.

Android: vfat; wince: FAT32 (FAT32 compatible with vfat File System)

Distribution of Dual-System Images in inand:

Init_raw_area_table: 1 block = 512 byte

Start (Block in unit) size (Block) Name
Image [0]:
--Efuse
Image [1]:
1 8kb (16) BL1
Image [2]:
17 16 KB (32) ENV
Image [3]:
49 512kb (1024) bl2
Image [4]:
1073 4 MB (8192) Kernel
Image [5]:
9265 26 MB (53248) RFS
Image [6]:
62513 XMB () eboot (wince)

The remaining space is the system partition of Android.