public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Oleg Uzenkov <o.uzenkov@unicore.co.ua>
To: Edgar Grimberg <edgar.grimberg@gmail.com>
Cc: eCos Discussion <ecos-discuss@sourceware.org>
Subject: Re: [ECOS] small custom bootloader to start an app stored in flash
Date: Wed, 22 Oct 2014 14:40:00 -0000	[thread overview]
Message-ID: <5447C1D0.3070906@unicore.co.ua> (raw)
In-Reply-To: <CAPrjMDCiZ0Lkwfgv=dfw8fhjmZXjeLAdgHSiiK9o6RZXLM-G=g@mail.gmail.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

  reply	other threads:[~2014-10-22 14:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21  8:27 Oleg Uzenkov
2014-10-21 11:02 ` Gary Thomas
2014-10-21 13:25 ` Edgar Grimberg
     [not found] ` <CAPrjMDAi=cqTSQ-d-c9FF53W-c6=v0j8rzSLQfuTcBQUY43Zpw@mail.gmail.com>
2014-10-22 11:08   ` Oleg Uzenkov
2014-10-22 13:17     ` Edgar Grimberg
2014-10-22 14:40       ` Oleg Uzenkov [this message]
2014-10-23  9:55         ` Edgar Grimberg
2014-10-23 12:53           ` Edgar Grimberg
2014-10-23 15:03             ` Oleg Uzenkov
2014-10-23 19:25               ` Rainer Arndt
2014-10-23 21:21               ` Sergei Gavrikov
2014-10-24  7:44                 ` Oleg Uzenkov
2014-10-24  8:36                   ` Sergei Gavrikov
2014-10-24  9:13                     ` Sergei Gavrikov
2014-10-24  9:13                     ` Oleg Uzenkov
2014-10-22 19:01     ` Rainer Arndt
2014-10-23 11:50       ` Oleg Uzenkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5447C1D0.3070906@unicore.co.ua \
    --to=o.uzenkov@unicore.co.ua \
    --cc=ecos-discuss@sourceware.org \
    --cc=edgar.grimberg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).