This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: small custom bootloader to start an app stored in flash
- From: Oleg Uzenkov <o dot uzenkov at unicore dot co dot ua>
- To: Edgar Grimberg <edgar dot grimberg at gmail dot com>
- Cc: eCos Discussion <ecos-discuss at sourceware dot org>
- Date: Wed, 22 Oct 2014 17:40:16 +0300
- Subject: Re: small custom bootloader to start an app stored in flash
- Authentication-results: sourceware.org; auth=none
- References: <544618E5 dot 90101 at unicore dot co dot ua> <CAPrjMDAi=cqTSQ-d-c9FF53W-c6=v0j8rzSLQfuTcBQUY43Zpw at mail dot gmail dot com> <54479031 dot 9080106 at unicore dot co dot ua> <CAPrjMDCiZ0Lkwfgv=dfw8fhjmZXjeLAdgHSiiK9o6RZXLM-G=g at mail dot gmail dot com>
May be I am missing something in the understanding of the principles.
I don't see anything obviously broken (I guess you would have spotted it).
If you have a JTAG debugger, now it's a good time to make use of it:
1. Check that you don't reach the infinite loop in your bootloader application.
Checked I do not reach while(1);
2. Insert a hardware breakpoint at address 0x08020000, to see if you
call the correct address from the bootloader.
3. Try single stepping when you get to 0x08020000, see if the code makes sense.
This is the outcome:
..
(gdb) x 0x08020000
0x8020000: 0x20020000
..
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x8000000
Loading section .ARM.extab, size 0x3c lma 0x8000008
Loading section .ARM.exidx, size 0xc8 lma 0x8000048
Loading section .text, size 0x58ac lma 0x8000110
Loading section .rodata, size 0x109 lma 0x80059c0
Loading section .data, size 0x268 lma 0x8005ad8
Start address 0x8000110, load size 23849
Transfer rate: 10 KB/sec, 3407 bytes/write.
(gdb) break *0x08020000
Note: breakpoints 4, 6, 8 and 10 also set at pc 0x8020000.
Breakpoint 11 at 0x8020000
(gdb) hbreak *0x08020000
Note: breakpoints 4, 6, 8, 10 and 11 also set at pc 0x8020000.
Hardware assisted breakpoint 12 at 0x8020000
(gdb) continue
Continuing.
Breakpoint 9, main () at jump.cpp:10
10 int main (void) {
(gdb) next
Breakpoint 3, main () at jump.cpp:12
12 diag_printf( "JUMP\n" );
(gdb) next
15 cyg_interrupt_disable();
(gdb) next
18 startApp1();
(gdb) next
Breakpoint 8, 0x08020000 in ?? ()
(gdb) next
Cannot find bounds of current function
(gdb)
.....
program just hangs when continued.
Something wrong here. Any ideas?
4. Try starting your application (0x08020000) from the debugger
directly, see if you get the printf.
...
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x8020000
Loading section .ARM.extab, size 0x3c lma 0x8020008
Loading section .ARM.exidx, size 0xc8 lma 0x8020048
Loading section .text, size 0x586c lma 0x8020110
Loading section .rodata, size 0x10d lma 0x8025980
Loading section .data, size 0x268 lma 0x8025a98
Start address 0x8020110, load size 23789
Transfer rate: 3 KB/sec, 3398 bytes/write.
(gdb) next
Cannot find bounds of current function
...
ROM startup build copies .data and .bss sections into ram, probably these
sections data gets overwritten.
They should get overwritten by the app startup sequence. This is OK.
Do I need to shift addresses of SECTION_sram, SECTION_data, SECTION_bss in
app's memory layout?
No, you won't need anything from the bootloader, you'll never return
execution to the bootloader (unless you reset the board).
$ arm-none-eabi-readelf -h app.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x8020111
As pointed previously, there is something strange with this address.
Can you try jumping to it from the bootloader?
Yes, I agree. I will try to find out why it is so, may be there is a bug
somewhere.
Edgar
Start of program headers: 52 (bytes into file)
Start of section headers: 24148 (bytes into file)
Flags: 0x5000002, has entry point, Version5
EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 12
Section header string table index: 11
$ arm-none-eabi-objdump -h app.elf
app.elf: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .rom_vectors 00000008 08020000 08020000 00000098 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .ARM.extab 0000003c 08020008 08020008 000000a0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .ARM.exidx 000000c8 08020048 08020048 000000e0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .text 0000586c 08020110 08020110 000001a8 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .rodata 0000010d 08025980 08025980 00005a18 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .eh_frame 00000008 08025a90 08025a90 00005b25 2**0
ALLOC
6 .data 00000268 20000288 08025a98 00005b28 2**3
CONTENTS, ALLOC, LOAD, DATA
7 .bss 000034e8 200004f0 08025d00 00005d90 2**3
ALLOC
8 .ARM.attributes 0000002d 00000000 00000000 00005d90 2**0
CONTENTS, READONLY
9 .comment 0000002a 00000000 00000000 00005dbd 2**0
CONTENTS, READONLY
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss