Study on the Problem of loading RTEMS mini2440 qemu simulation from uboot

Well, first of all, I would like to thank rickleaf for introducing the qemu simulation mini2440 solution to me and sharing the BSP transplanted from mini2440 to me. This greatly increases my working speed.

Here is an article about migrating rtems4.9.5 to qemu.

Http://blog.csdn.net/rickleaf/archive/2011/03/16/6254361.aspx

 

Although it can be run at that time, it is loaded using GDB. Instead of using the uboot loading method. There has been a problem with the uboot loading method.

Rickleaf studied and found that the loading and startup addresses are both 0x30000100. For details, see blog:

 

Http://blog.csdn.net/rickleaf/archive/2011/03/18/6260292.aspx

 

But for the reason described in this article:

 

/---------------------------- The following text is taken from rickleaf's blog ---------------------------------------/

2. Explore the causes

After being converted to a binfile, the pseudo commands before the entry do not exist,

Think about it. Isn't it reserved if it's not burned there? :-)

/---------------------------- The above text is taken from the rickleaf blog ---------------------------------------/

 

I have different opinions on this reason. I did the following:

First, use the compiled mini2440 BSP to compile the hello_world_c example. Officially. After compilation is successful, there is a hello. Num file under O-optimize under hello_world_c. This is the symbolic position in hello.exe (actually in ELF format. The first 22 rows are:

 

W_jv_registerclasses
W _ deregister_frame_info
W _ register_frame_info
00000100 A _ abt_stack_size
00000400 A _ fiq_stack_size
00001000 A _ irq_stack_size
00001000 A _ svc_stack_size
04000000 A _ sdram_size
30000000 A _ sdram_base
30000000 B arm_exception_table
30000000 B arm_reset_vect
30000004 B arm_undef_vect
30000008 B arm_swi_vect
300366c B arm_iabrt_vect
30000010 B arm_dabrt_vect
30000018 B arm_irq_vect
3000001c B arm_fiq_vect
30000020 B rtems_vector_table
30000040 B bsp_vector_table

30000100 T _ axf_text_start
30000100 T _ start
3000026c t reset_handler

 

From 0x3000 0000 3000 to 0x0040, we can see that there is something. And the symbol is B. What is B? refer to the official documentation:

The value of this symbol appears in the non-initialized data segment (BSS. For example, define Global static int test in a file. The test type is B and is located in the BSS section. The value indicates the offset of the symbol in the BSS segment. Generally, BSS segments are allocated in Ram.

 

Arm_exception_table and arm_reset_vect are static global variables, but they are not initialized. Well, I used arm_reset_vect to search for the entire BSP code and did not find the variable initialized or declared in the code. The Using LD document describes this issue. In the connection script, you can use the assign value statement to declare some global variables. The following is the original article on the Expression section I translated:

 

 

 

 

Since it is defined in the connection script, let's look at the RTEMS connection script of mini2440. I posted the first 90 rows of the script written by rickleaf.

/* <Br/> * mini2440 linker script <br/> * written by Ricky Wu <rickleaf.wu@gmail.com> <br/> * the license and distribution terms for this file may be <br/> * found in the file license in this distribution or at <br/> * http://www.rtems.com/license/LICENSE. <br/> * $ ID: linkcmds, v 1.1 2008/05/06 21:01:27 Joel exp $ <br/> */<br/> output_format ("elf32-littlearm", "elf32 -Bigarm "," elf32-littlearm ") <br/> output_arch (ARM) <br/> entry (_ start) <br/>/* search_dir (/usr/local/RTEMS-arm-Dev-tools/ARM-RTEMS/LIB ); */<br/> memory {<br/> SDRAM: Origin = 0x30000000, length = 128 M <br/>}< br/>/* <br/> * declare some sizes. <br/> */<br/>/* the base for SDRAM is set to umon's apprambase */<br/> _ sdram_base = defined (_ sdram_base )? _ Sdram_base: 0x30000000; <br/> _ sdram_size = defined (_ sdram_size )? _ Sdram_size: 128 M; <br/> _ irq_stack_size = defined (_ irq_stack_size )? _ Irq_stack_size: 0x1000; <br/> _ fiq_stack_size = defined (_ fiq_stack_size )? _ Fiq_stack_size: 0x400; <br/> _ abt_stack_size = defined (_ abt_stack_size )? _ Abt_stack_size: 0x100; <br/> _ svc_stack_size = defined (_ svc_stack_size )? _ Svc_stack_size: 0x1000; <br/>/* do we need any of these for elf? <Br/> _ dynamic = 0; */<br/> sections <br/> {<br/>. base: <br/>{< br/> arm_exception_table = .; <br/> arm_reset_vect = .; /* 0x00 */<br/>. + = 4; <br/> arm_undef_vect = .; /* 0x04 */<br/>. + = 4; <br/> arm_swi_vect = .; /* 0x08 */<br/>. + = 4; <br/> arm_iabrt_vect = .; /* 0x0c */<br/>. + = 4; <br/> arm_dabrt_vect = .; /* 0x10 */<br/>. + = 4; <br/>/* No vector here */<br/>. + = 4; <br/> arm_irq_vect = .; /* 0x18 */<br/>. + = 4; <br/> arm_fiq_vect = .; /* 0x1c */<br/>. + = 4; <br/>/* fixme: */<br/> rtems_vector_table = .; <br/>. + = (8*4);/* 8 arm interrupts */</P> <p> bsp_vector_table = .; <br/>. + = (32*4);/* 32 s3c2400 interrupts */<br/>. = align (0x100); <br/>}> SDRAM <br/>. text: <br/>{< br/> _ axf_text_start = .; <br/> * (exclude_file (* text. iwram *). text) <br/> *(. text. *) <br/> *(. stub)

 

From the connection script, the address of the SDRAM starts from 0x3000 0000. The first place is the. Base segment, which occupies 0x100 bytes. Actually there are not so many, because the. = align (0x100) statement makes the address counter aligned by 0x100. Make the. Text address start from 0x3000 0100. We can see that the script's 15th line entry (_ start) is actually the first command and the first command of. Text. There is no doubt that the first RTEMS command is located at 0x3000 0100.

 

The entire image is displayed in linkcmd starting from 0x3000 0000, and 0x3000 0100 is the first command. Why input the following command in uboot:

TFTP 30000000 image. Bin

Go 1, 30000100

No response?

(((

Compile the compiled hello.exe using the command:

Arm-rtems4.9-objcopy-O binary hello.exe/tftpboot/image. Bin

(My TFTP server folder is in/tftpboot, which varies from person to person)

)))

Only one sentence: # Starting application at 0x30000100...

 

According to the preceding hello. nm, it is assumed that the uninitialized data segment is not included in the image if it is at the end of the image or at the beginning of the image.

 

So I want to prove this conjecture. Modify the script:

 

Sections
{
. Base:
{
Arm_exception_table = .;

Arm_reset_vect =.;/* 0x00 */
Long (200)/*. + = 4; * // * modified by Bacon */

Arm_undef_vect =.;/* 0x04 */

 

Long indicates that a 4-byte integer is stored in the address counter position. Here is the storage of 200, purely for testing.

Well, recompile the rtems bsp and hello World sample of mini2440.

Check hello. nm again. The first 22 rows are:

 

W_jv_registerclasses
W _ deregister_frame_info
W _ register_frame_info
00000100 A _ abt_stack_size
00000400 A _ fiq_stack_size
00001000 A _ irq_stack_size
00001000 A _ svc_stack_size
04000000 A _ sdram_size
30000000 A _ sdram_base
30000000 D arm_exception_table
30000000 D arm_reset_vect
30000004 D arm_undef_vect
30000008 D arm_swi_vect
300366c D arm_iabrt_vect
30000010 D arm_dabrt_vect
30000018 D arm_irq_vect
3000001c D arm_fiq_vect
30000020 D rtems_vector_table
30000040 D bsp_vector_table

30000100 T _ axf_text_start
30000100 T _ start
3000026c t reset_handler

 

 

Note: changed from symbol B to symbol D.

D indicates that the symbol is in the initialized data segment. Generally, it is allocated to the data section. For example, if the global int baud_table [5] = {9600,192 00, 38400,576 00, 115200} is defined, it is allocated to the initialization data segment.

 

Then enter ~ /Qemu folder, run:

./Mini2440/mini2440_start.sh

Start qemu

(Please refer to: http://blog.csdn.net/coolbacon/archive/2011/03/16/6252938.aspx for details)

Enter the following command:

TFTP 30000000 image. Bin

Go 1, 30000100

 

Haha, we can see hello World !!

 

The following figure shows the time for truth:

 

 

 

 

 

This confirms my speculation. Note: The final image does not contain uninitialized data segments.

There is still room for further research on this issue. The following are three situations where the space location of the data segment is not initialized globally:

 

I think both the first and third types can be missing, that is, the final memory image does not include "uninitialized data segments globally ". In the second case, it is worth studying. Based on my experience, I think that if "other segments" need to be reflected in the final image, "The Global uninitialized data segment" must also be reflected in the image and must be included. If other segments do not need to be reflected, the uninitialized data segments will not be reflected in the final image. (Leave empty to make an experiment to verify my thoughts .)

 

It is the nature of a technician to prove who is right and who is wrong and to explore the truth. I would like to thank rickleaf for its contribution. I would not think of this layer without him.