Qt210, U-Boot porting (3)

Find the region on the Internet.

In s5pv210_irom_applicationnote_preliminary_20091126133: 2.9 header information data for Boot Code Description, This section describes the composition of bl1.

The U-boot-Samsung-dev/sd_fusing directory contains the BL1 tool and source code.

After reading the source code, one thing I don't understand is that we looked at U-boot source code before, can be said to be from the u-boot.bin file 0x00000000 position to start execution, but from sd_fdisk.c source code, the first 16 bytes were modified by the program, so the u-boot.bin should be executed starting from 0x00000010. But after reading the U-boot-Samsung-dev/CPU/s5pc11x/start. s file, this problem is solved. Compare the start. s file with the official U-boot source code, with the following output:

#if defined(CONFIG_EVT1) && !defined(CONFIG_FUSED).word 0x2000.word 0x0.word 0x0.word 0x0#endif

Exactly 16 bytes. The first word indicates 8192 bytes. The size of BL1 is 8 K.

So it will solve the article on why the u-boot.bin to burn to seek = 49: Samsung modified U-boot of the first 8 K code inside, will load bl2 from seek = 49, that is, U-boot.

Combine the start. s file, u-boot.bin file, u-boot.map file, u-boot.dis file to understand the start. s file. The u-boot.dis file is an assembly of the u-boot.bin.

First, read the U-boot source code provided by Samsung to transplant the official U-boot.

Use the development version of the provided SD-bl1-8k.bin, and then compile your own U-boot-Samsung-dev source code, burn to seek = 49, there is no reaction, several smdkv210xxxxx_config are compiled, and start at the beginning. s, when it is started, it will not work if you try to light it. There is no such phenomenon. It has plagued me for a long time. It is really painful and there is no progress stuck here.

Later thought, the SD-bl1-8k.bin is separated from the front of the u-boot.bin of the first 8 K, then the SD-bl1-8k.bin should be separated from the u-boot.nand_restore.sdboot of the first 8 K, so may be and I compiled Out Of The u-boot.bin is not compatible, and I also have contrast u-boot.nand_restore.sdboot and I compiled the u-boot.bin, the first 512 bytes inside there are a few different places, especially the _ bss_start variable is only different.

If you think of it, it is not clear that the SD-bl1-8k.bin is jump to the U-boot where to start the execution, if you want to directly compile BL1, starting from BL1. If u-boot-Samsung-Dev is compiled again, which of the following statements can be used to compile smdkv210xxx_config, and the position I add is start. S:

reset:/* * set the cpu to SVC32 mode and IRQ & FIQ disable */@;mrsr0,cpsr@;bicr0,r0,#0x1f@;orrr0,r0,#0xd3@;msrcpsr,r0msrcpsr_c, #0xd3@ I & F disable, Mode: 0x13 - SVCldr r0, =0xE0200C00ldr r1, =0x1111str r1, [r0]ldr r1, =0x0Fstr r1, [r0, #4]

However, the lamp assembly is added to start. S. After compilation, use:

./sd_fusing/mkbl1 u-boot.bin bl1.bin 8192

Generate bl1.bin, and then

dd seek=1 if=bl1.bin of=/dev/sdc

Burned to the SD card. As a result, all the four lights of qt210 are on. It indicates that the light is successfully lit. It seems that you have to start with BL1. Familiarize yourself with the U-boot source code ......

Qt210 has four LED lights, corresponding to gph0_0, gph0_1, gph0_2, and gph0_3 respectively. The method of lighting is to first configure the corresponding gph0con as output, and then configure the bit corresponding to gph0dat to output the level.

GPH0CON, R/W, Address = 0xE020_0C00GPH0DAT, R/W, Address = 0xE020_0C04

For more information about these two registers, see 2.2.56.1 port group gph0 control register (gph0con, R/W, address = 0xe020_0c00) and 2.2.56.2 port group gph0 control register (gph0dat, r/W, address = 0xe020_0c04.

Compile the lighting code:

ldr r0, =0xE0200C00ldr r1, =0x1111str r1, [r0]ldr r1, =0x0Fstr r1, [r0, #4]

ldr r1, =0x1111

Gph0_0, gph0_1, gph0_2, and gph0_3 are all output.

ldr r1, =0x0F

It means that gph0_0, gph0_1, gph0_2, and gph0_3 are all output 1.

C language lighting:

*（volatile unsignet int *)0xE0200C00 = 0x00001111;*（volatile unsignet int *)0xE0200C04 = 0x0000000F;

A little progress has finally been made!