nboot reads the image from NAND flash to the memory and executes it, and eboot downloads the image from the Ethernet (using tftp) to the memory and executes it. Burn nboot.nb0 to block 0 and eboot.nb0 to block 2. When starting up, nboot reads eboot from flash and executes it. Then nk.bin can be downloaded to the target board through pb and executed. The development machine and the target board can be directly connected with a cross cable.

nboot means nand flash bootloader. S3C2410 can boot directly from nand flash, but it cannot exceed 4k. nboot is the first code to be executed after the system starts. There are two types of code, one is to jump to eboot; the other is to jump to nk. The main function is actually in eboot.

The structure and generation method of NBOOT

Previous nboot was compiled and linked with ADS, which is simple and clear. The nboot included in the BSP this time was generated by the WinCE tool chain. The resulting .nb0 was actually 12KB, while Samsung's Steppingstone was only 4KB. How to cut it? I spent some time looking at .log .map .rel .bib .bin .nb0 carefully, and finally figured out that the 12KB nboot contains something.

startup.s file:

OPT 2

INCLUDE kxarm.h

OPT 1

OPT 128

IMPORT main

STARTUPTEXT

LEAF_ENTRY StartUp

b main

END

main.c file:

#include

#include

#include

ROMHDR * volatile const pTOC = (ROMHDR *)-1;

static int gI1;

static char *gBuf = "global str";

int test(char *str)

{

int ret = 0;

while (*str)

{

ret += *str++;

}

return ret;

}

void main(void)

{

gI1 = 1;

test("is .rdata str?");

test(gBuf);

}

.map information:

Preferred load address is 00010000

Start Length Name Class

0001:00000000 00000004H .astart CODE

0001:00000010 0000003bH .rdata CODE

0001:0000004c 00000024H .rdata$debug CODE

p>

0001:00000070 0000004cH .text CODE

0001:000000bc 00000000H .edata CODE

0002:00000000 00000008H .data DATA

0002:00000008 00000004H .bss DATA

0003:00000000 00000008H .pdata DATA

entry point at 0001:00000000

where

.rdata: pTOC , 2 strings

.data: gBuf, gI2

.bss: gI1

build.log information:

Module Section Start Length psize vsize Filler

nk.exe .text 00001000 4096 512 188 o32_rva=00001000

nk.exe .pdata 00002000 4096 512 8 o32_rva=00003000

nk.exe .data 000010bc 5 5 12 FILLER->33ff0000

nk.exe E32 000010c4 112 FILLER

nk.exe O32 00001134 72 FILLER

Module Section Start Length psize vsize Filler

nk.exe FileName 0000117c 7 FILLER

Unfilled ROM holes (address, length):

00002008 4088 00001184 3708

Total space 7796 in 2 ranges

Based on the .map information:

.text contains: .astart .rdata .rdata$debug .text .edata, which is 0xBC( 188)

.pdata contains: .pdata

.data contains: .data .bss. The reason why psize is 5 is because "static int gI2 = 2" only occupies 1B< /p>

Note: The .text and .data sections of the .bin file are consecutive.

View the record info of .bin:

Image Start = 0x00000000, length = 0x00002008

Record [ 0] : Start = 0x00000000, Length = 0x00000004, Chksum = 0x000001EB

Record [ 1] : Start = 0x00000040, Length = 0x00000008, Chksum = 0x000001A5

Record [ 2] : Start = 0x00000048, Length = 0x00000004, Chksum = 0x0000 0095

Record [ 3] : Start = 0x00001000, Length = 0x00000184, Chksum = 0x000046D8

Record [ 4] : Start = 0x00001184, Length = 0x00000054, Chksum = 0x000007B2

Record [ 5] : Start = 0x000011D8, Length = 0x00000030, Chksum = 0x000008F6

Record [ 6] : Start = 0x00002000, Length = 0x00000008, Chksum = 0x000000C3

Record [ 7 ] : Start = 0x00000000, Length = 0x00001000, Chksum = 0x00000000

Start address = 0x00001000

Checking record #4 for potential TOC (ROMOFFSET = 0x00000000)

Found pTOC = 0x00001184

ROMOFFSET = 0x00000000

Use ADS to disassemble the expanded .nb0:

0KB~4KB: REC[0] is b 0x1000 jump Transfer command; REC[1/2] seems to be a signature or something.

4KB~8KB: REC[3] contains all Sections (except .pdata); REC[4] is ROMHDR; REC[5] is unknown

8KB~12KB: REC[ 6] is .pdata

Start and Chksum of REC[7] are both 0, then Length indicates EntryPoint.

If relocation is not considered, just burn the 4KB starting from 0x1000 of .nb0 into NAND Flash and you are done.

Simplify the main.c file:

#include

#include

#include

ROMHDR * volatile const pTOC = (ROMHDR *)-1;

void test(char * str)

{

while(*str)

{

*(volatile unsigned char *)0x1234 = *str++;

}

}

void main(void)

{

test("Step ldr\r\n");

}< /p>

.rel information:

0003 0001 00001088 00000000

That is, 0x1088 needs to be relocated.

Use ADS to disassemble the expanded .nb0:

0x1064 ldr r2,0x00001088; = #0x00000030

The value of 0x1088 is 0x30, according to the .map file It can be seen that 0x1030 stores the string "Step ldr\r\n"

So after removing the first 4KB page of .nb0, 0x30 is the address of the string.

If the Start and ROMSTART of RAMIMAGE in the .bib file are both from 0->0x1000, then the value of 0x1088 is 0x2030, and the first 4KB page of .nb0 cannot be removed

The main function of Nboot (Nand flash bootloader) is to initialize the hardware, copy the image of the later relatively complete boot program such as eboot to SDRAM, and then jump to SDRAM to continue running eboot.

Why is there such a thing as nboot? In fact, it is mainly because the current SOC takes into account the cost issue. Basically, it comes with a nand flash controller and supports booting nand flash boot to replace the relative For expensive nor flash.

Generally speaking, the nand flash controller will have a built-in buffer such as SRAM to support the booting of nand flash. In the nand boot mode, when the board is powered on, the nand controller will automatically The data of the first buffer size of nand flash is automatically copied to the buffer and then the pc pointer can read instructions directly from the buffer. Generally speaking, this buffer will not be very large. The 2410 chip is 4k, and the imx21 like Freescale is only 2k. So due to this limitation, we can only split the bootloader into two parts, and the first part is used to complete the basic initialization function. , and the latter part completes a more complete function, allowing the controller to automatically copy the previous part, and then the former part copies the latter part to RAM, so that the boot program can do whatever it wants to do.

In fact, it is not difficult to implement an nboot. The following is a general process:

1. Of course, the clock is configured. Without this system, it cannot run o(∩_∩ )o…

2. Needless to say, the configuration of SDRAM is also indispensable, otherwise how would we copy the program to SDRAM.

3. This is the configuration of the flash controller. Generally speaking, it means configuring the GPIO and the corresponding controller register.

4. Copy the file from nand to SDRAM. When reading nand flash, generally you pull the chip to select the bit first, then send the command, then the address, and finally the reading.

After completing the above steps, the entire nboot is almost complete. However, there are a few points that need special attention when developing under WinCE:

1. Because PB is used to compile , so in order to generate the .nb0 file, you must add:

pTOC DCD -1

EXPORT pTOC

This is to let ROMIMG.exe Used when making images.

2. Generate .nb0 files and bib files are also indispensable.

3. Because of the Microsoft compiler, when we compile .nb0 according to the normal method, the first 4K are empty, so it is impossible to burn the compiled .nb0 directly. Used, so change it in bib:

Define: NBOOT 00000000 00002000 RAMIMAGE to a size of 8k, and then the following

ROMSTART=00001000

ROMSIZE=1000

Move the start address back, and then change the size to 4k, so that the nb0 that comes out will cut off the empty 4k in front.

If you have done all the above, there should basically be no problems.