public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] small custom bootloader to start an app stored in flash
@ 2014-10-21  8:27 Oleg Uzenkov
  2014-10-21 11:02 ` Gary Thomas
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-21  8:27 UTC (permalink / raw)
  To: eCos Discussion

Hello Everyone,

I would like to make a small custom bootloader (not considering RedBoot) 
that would implement a simple function of checking a flag (some bytes in 
memory) and then jumping to one of the applications stored in internal 
flash.

Something like this:

internal flash memory:

------------------  0x08000000
| bootloader  |
|                    |
------------------
|_____            |
|flag |            |
------------------
|                    |
|                    |
------------------
| app1           |
|                    |
------------------
| app2           |
|                    |
------------------
|                    |
|                    |
--------------

Basically, if flag is true then start app1 else start app2.

I suppose bootloader would be a simple eCos app with ROM startup. 
Applications in flash probably should also be built for ROM startup.
When the jump is made app's .data and .bss sections should be copied 
into RAM...

Any ideas how to make a jump to start an app? May be some sample code 
showing how to do it in eCos? May be someone has done it already?

I would appreciate any help on this.

Best wishes,

Oleg

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-21  8:27 [ECOS] small custom bootloader to start an app stored in flash 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>
  2 siblings, 0 replies; 17+ messages in thread
From: Gary Thomas @ 2014-10-21 11:02 UTC (permalink / raw)
  To: ecos-discuss

On 2014-10-21 02:27, Oleg Uzenkov wrote:
> Hello Everyone,
>
> I would like to make a small custom bootloader (not considering RedBoot) that would implement a simple function of checking a flag (some bytes in memory) and then jumping to one of
> the applications stored in internal flash.
>
> Something like this:
>
> internal flash memory:
>
> ------------------  0x08000000
> | bootloader  |
> |                    |
> ------------------
> |_____            |
> |flag |            |
> ------------------
> |                    |
> |                    |
> ------------------
> | app1           |
> |                    |
> ------------------
> | app2           |
> |                    |
> ------------------
> |                    |
> |                    |
> --------------
>
> Basically, if flag is true then start app1 else start app2.
>
> I suppose bootloader would be a simple eCos app with ROM startup. Applications in flash probably should also be built for ROM startup.
> When the jump is made app's .data and .bss sections should be copied into RAM...
>
> Any ideas how to make a jump to start an app? May be some sample code showing how to do it in eCos? May be someone has done it already?
>
> I would appreciate any help on this.

You've already mentioned the answer - RedBoot!

RedBoot is just another eCos application which does all the
things you are considering.  I can understand not wanting to
include RedBoot in your design (although it can be extremely
useful, especially during development), but looking through
the sources you'll find guidance on all the topics you are
looking for.

Good luck

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-21  8:27 [ECOS] small custom bootloader to start an app stored in flash 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>
  2 siblings, 0 replies; 17+ messages in thread
From: Edgar Grimberg @ 2014-10-21 13:25 UTC (permalink / raw)
  To: eCos Discussion

>
> Any ideas how to make a jump to start an app? May be some sample code
> showing how to do it in eCos? May be someone has done it already?

// Make a function pointer and assigned it to the address you want to jump to.
void (*startApp1)(void) = 0x08002000 ;

// Disable the interrupts.
cyg_interrupt_disable();

//Call the function.
startApp1();

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
       [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 19:01     ` Rainer Arndt
  0 siblings, 2 replies; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-22 11:08 UTC (permalink / raw)
  To: Edgar Grimberg; +Cc: eCos Discussion

Thanks,
>> Any ideas how to make a jump to start an app? May be some sample code
>> showing how to do it in eCos? May be someone has done it already?
> // Make a function pointer and assigned it to the address you want to jump to.
> void (*startApp1)(void) = 0x08002000 ;
>
> // Disable the interrupts.
> cyg_interrupt_disable();
>
> //Call the function.
> startApp1();
I have tried it but could not get it working yet (stm32f4-discovery board).

May be I am missing something in the understanding of the principles.

Please could you check.

1. Here is the code of my bootloader:

...
static void (*startApp)(void) = ( void(*)(void) ) (0x08020000) ;

int main (void) {

   diag_printf( "IN JUMP\n" );

   cyg_interrupt_disable();

   startApp();

   while (1);

   return 0;
}

I build it with ROM startup and flash at 0x08000000

mlt files:

*.ldi:

MEMORY
{
     ram   : ORIGIN = 0x20000000, LENGTH = 
0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
     flash : ORIGIN = 0x08000000, LENGTH = 0x00100000
     ccm   : ORIGIN = 0x10000000, LENGTH = 0x00010000
}

hal_vsr_table = 0x20000000;
hal_virtual_vector_table = hal_vsr_table + 98*4;
#if defined(CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT)
hal_virtual_vector_table_end = hal_virtual_vector_table + 64*4;
#else // zero size virtual vector table
hal_virtual_vector_table_end = hal_virtual_vector_table;
#endif

// SRAM is 128k.
hal_startup_stack = 0x20000000 + 1024*128;

SECTIONS
{
     SECTIONS_BEGIN
     USER_SECTION (ccm, ccm, 0x10000000 (NOLOAD), LMA_EQ_VMA)
     SECTION_rom_vectors (flash, 0x08000000, LMA_EQ_VMA)
     SECTION_RELOCS (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_text (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fini (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_rodata (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_rodata1 (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fixup (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_gcc_except_table (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_eh_frame (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_got (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_sram (ram, hal_virtual_vector_table_end, FOLLOWING (.got))
     SECTION_data (ram, ALIGN( 0x8), FOLLOWING (.sram))
     SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
     SECTIONS_END
}

*.h:
#define CYGMEM_REGION_ram (0x20000000)
#define CYGMEM_REGION_ram_SIZE 
(0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_ccm (0x10000000)
#define CYGMEM_REGION_ccm_SIZE (0x00010000)
#define CYGMEM_REGION_ccm_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_flash (0x08000000)
#define CYGMEM_REGION_flash_SIZE (0x00100000)
#define CYGMEM_REGION_flash_ATTR (CYGMEM_REGION_ATTR_R | 
CYGMEM_REGION_ATTR_W)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__heap1) [];
#endif
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE 
(CYGMEM_REGION_ram+CYGMEM_REGION_ram_SIZE - (size_t) CYG_LABEL_NAME 
(__heap1))

2. Here is the code of my app to which I want to jump to:

int main (void) {

   diag_printf( "IN APP\n" );

   while (1);

   return 0;
}

I build it with ROM startup and flash it at 0x08020000

mlt files:

*.ldi:

MEMORY
{
     ram   : ORIGIN = 0x20000000, LENGTH = 
0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
     flash : ORIGIN = 0x08020000, LENGTH = 0x00100000 - 0x20000
     ccm   : ORIGIN = 0x10000000, LENGTH = 0x00010000
}

hal_vsr_table = 0x20000000;
hal_virtual_vector_table = hal_vsr_table + 98*4;
#if defined(CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT)
hal_virtual_vector_table_end = hal_virtual_vector_table + 64*4;
#else // zero size virtual vector table
hal_virtual_vector_table_end = hal_virtual_vector_table;
#endif

// SRAM is 128k.
hal_startup_stack = 0x20000000 + 1024*128;

SECTIONS
{
     SECTIONS_BEGIN
     USER_SECTION (ccm, ccm, 0x10000000 (NOLOAD), LMA_EQ_VMA)
     SECTION_rom_vectors (flash, 0x08020000, LMA_EQ_VMA)
     SECTION_RELOCS (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_text (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fini (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_rodata (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_rodata1 (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fixup (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_gcc_except_table (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_eh_frame (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_got (flash, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_sram (ram, hal_virtual_vector_table_end, FOLLOWING (.got))
     SECTION_data (ram, ALIGN( 0x8), FOLLOWING (.sram))
     SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
     SECTIONS_END
}

*.h:
#define CYGMEM_REGION_ram (0x20000000)
#define CYGMEM_REGION_ram_SIZE 
(0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_ccm (0x10000000)
#define CYGMEM_REGION_ccm_SIZE (0x00010000)
#define CYGMEM_REGION_ccm_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_flash (0x08020000)
#define CYGMEM_REGION_flash_SIZE (0x00100000 - 0x20000)
#define CYGMEM_REGION_flash_ATTR (CYGMEM_REGION_ATTR_R | 
CYGMEM_REGION_ATTR_W)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__heap1) [];
#endif
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE 
(CYGMEM_REGION_ram+CYGMEM_REGION_ram_SIZE - (size_t) CYG_LABEL_NAME 
(__heap1))

3. I am expecting output to be:
IN JUMP
IN APP

But I do not get to IN APP.

What am I doing wrong?

I tried to jump to 0x08020004 address as it is where hal_reset_vsr is, 
but still no luck.

ROM startup build copies .data and .bss sections into ram, probably 
these sections data gets overwritten.

Do I need to shift addresses of SECTION_sram, SECTION_data, SECTION_bss  
in app's memory layout?

Oleg

P.S:
$ 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
   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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-22 11:08   ` Oleg Uzenkov
@ 2014-10-22 13:17     ` Edgar Grimberg
  2014-10-22 14:40       ` Oleg Uzenkov
  2014-10-22 19:01     ` Rainer Arndt
  1 sibling, 1 reply; 17+ messages in thread
From: Edgar Grimberg @ 2014-10-22 13:17 UTC (permalink / raw)
  To: Oleg Uzenkov; +Cc: eCos Discussion

>
> 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.
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.
4. Try starting your application (0x08020000) from the debugger
directly, see if you get the printf.


> 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?

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-22 13:17     ` Edgar Grimberg
@ 2014-10-22 14:40       ` Oleg Uzenkov
  2014-10-23  9:55         ` Edgar Grimberg
  0 siblings, 1 reply; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-22 14:40 UTC (permalink / raw)
  To: Edgar Grimberg; +Cc: eCos Discussion


>> 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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-22 11:08   ` Oleg Uzenkov
  2014-10-22 13:17     ` Edgar Grimberg
@ 2014-10-22 19:01     ` Rainer Arndt
  2014-10-23 11:50       ` Oleg Uzenkov
  1 sibling, 1 reply; 17+ messages in thread
From: Rainer Arndt @ 2014-10-22 19:01 UTC (permalink / raw)
  To: Oleg Uzenkov, Edgar Grimberg; +Cc: eCos Discussion

Am 22. Oktober 2014 13:08:33 MESZ, schrieb Oleg Uzenkov <o.uzenkov@unicore.co.ua>:
>Thanks,
>>> Any ideas how to make a jump to start an app? May be some sample
>code
>>> showing how to do it in eCos? May be someone has done it already?
>> // Make a function pointer and assigned it to the address you want to
>jump to.
>> void (*startApp1)(void) = 0x08002000 ;
>>
>> // Disable the interrupts.
>> cyg_interrupt_disable();
>>
>> //Call the function.
>> startApp1();
>I have tried it but could not get it working yet (stm32f4-discovery
>board).
>
>May be I am missing something in the understanding of the principles.
>
>Please could you check.
>
>1. Here is the code of my bootloader:
>
>...
>static void (*startApp)(void) = ( void(*)(void) ) (0x08020000) ;
>
>int main (void) {
>
>   diag_printf( "IN JUMP\n" );
>
>   cyg_interrupt_disable();
>
>   startApp();
>
>   while (1);
>
>   return 0;
>}
>
>I build it with ROM startup and flash at 0x08000000
>
>mlt files:
>
>*.ldi:
>
>MEMORY
>{
>     ram   : ORIGIN = 0x20000000, LENGTH = 
>0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
>     flash : ORIGIN = 0x08000000, LENGTH = 0x00100000
>     ccm   : ORIGIN = 0x10000000, LENGTH = 0x00010000
>}
>
>hal_vsr_table = 0x20000000;
>hal_virtual_vector_table = hal_vsr_table + 98*4;
>#if defined(CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT)
>hal_virtual_vector_table_end = hal_virtual_vector_table + 64*4;
>#else // zero size virtual vector table
>hal_virtual_vector_table_end = hal_virtual_vector_table;
>#endif
>
>// SRAM is 128k.
>hal_startup_stack = 0x20000000 + 1024*128;
>
>SECTIONS
>{
>     SECTIONS_BEGIN
>     USER_SECTION (ccm, ccm, 0x10000000 (NOLOAD), LMA_EQ_VMA)
>     SECTION_rom_vectors (flash, 0x08000000, LMA_EQ_VMA)
>     SECTION_RELOCS (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_text (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_fini (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_rodata (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_rodata1 (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_fixup (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_gcc_except_table (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_eh_frame (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_got (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_sram (ram, hal_virtual_vector_table_end, FOLLOWING (.got))
>     SECTION_data (ram, ALIGN( 0x8), FOLLOWING (.sram))
>     SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
>     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
>     SECTIONS_END
>}
>
>*.h:
>#define CYGMEM_REGION_ram (0x20000000)
>#define CYGMEM_REGION_ram_SIZE 
>(0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE)
>#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R |
>CYGMEM_REGION_ATTR_W)
>#define CYGMEM_REGION_ccm (0x10000000)
>#define CYGMEM_REGION_ccm_SIZE (0x00010000)
>#define CYGMEM_REGION_ccm_ATTR (CYGMEM_REGION_ATTR_R |
>CYGMEM_REGION_ATTR_W)
>#define CYGMEM_REGION_flash (0x08000000)
>#define CYGMEM_REGION_flash_SIZE (0x00100000)
>#define CYGMEM_REGION_flash_ATTR (CYGMEM_REGION_ATTR_R | 
>CYGMEM_REGION_ATTR_W)
>#ifndef __ASSEMBLER__
>extern char CYG_LABEL_NAME (__heap1) [];
>#endif
>#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
>#define CYGMEM_SECTION_heap1_SIZE 
>(CYGMEM_REGION_ram+CYGMEM_REGION_ram_SIZE - (size_t) CYG_LABEL_NAME 
>(__heap1))
>
>2. Here is the code of my app to which I want to jump to:
>
>int main (void) {
>
>   diag_printf( "IN APP\n" );
>
>   while (1);
>
>   return 0;
>}
>
>I build it with ROM startup and flash it at 0x08020000
>
>mlt files:
>
>*.ldi:
>
>MEMORY
>{
>     ram   : ORIGIN = 0x20000000, LENGTH = 
>0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
>     flash : ORIGIN = 0x08020000, LENGTH = 0x00100000 - 0x20000
>     ccm   : ORIGIN = 0x10000000, LENGTH = 0x00010000
>}
>
>hal_vsr_table = 0x20000000;
>hal_virtual_vector_table = hal_vsr_table + 98*4;
>#if defined(CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT)
>hal_virtual_vector_table_end = hal_virtual_vector_table + 64*4;
>#else // zero size virtual vector table
>hal_virtual_vector_table_end = hal_virtual_vector_table;
>#endif
>
>// SRAM is 128k.
>hal_startup_stack = 0x20000000 + 1024*128;
>
>SECTIONS
>{
>     SECTIONS_BEGIN
>     USER_SECTION (ccm, ccm, 0x10000000 (NOLOAD), LMA_EQ_VMA)
>     SECTION_rom_vectors (flash, 0x08020000, LMA_EQ_VMA)
>     SECTION_RELOCS (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_text (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_fini (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_rodata (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_rodata1 (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_fixup (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_gcc_except_table (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_eh_frame (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_got (flash, ALIGN (0x8), LMA_EQ_VMA)
>     SECTION_sram (ram, hal_virtual_vector_table_end, FOLLOWING (.got))
>     SECTION_data (ram, ALIGN( 0x8), FOLLOWING (.sram))
>     SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
>     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
>     SECTIONS_END
>}
>
>*.h:
>#define CYGMEM_REGION_ram (0x20000000)
>#define CYGMEM_REGION_ram_SIZE 
>(0x00020000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE)
>#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R |
>CYGMEM_REGION_ATTR_W)
>#define CYGMEM_REGION_ccm (0x10000000)
>#define CYGMEM_REGION_ccm_SIZE (0x00010000)
>#define CYGMEM_REGION_ccm_ATTR (CYGMEM_REGION_ATTR_R |
>CYGMEM_REGION_ATTR_W)
>#define CYGMEM_REGION_flash (0x08020000)
>#define CYGMEM_REGION_flash_SIZE (0x00100000 - 0x20000)
>#define CYGMEM_REGION_flash_ATTR (CYGMEM_REGION_ATTR_R | 
>CYGMEM_REGION_ATTR_W)
>#ifndef __ASSEMBLER__
>extern char CYG_LABEL_NAME (__heap1) [];
>#endif
>#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
>#define CYGMEM_SECTION_heap1_SIZE 
>(CYGMEM_REGION_ram+CYGMEM_REGION_ram_SIZE - (size_t) CYG_LABEL_NAME 
>(__heap1))
>
>3. I am expecting output to be:
>IN JUMP
>IN APP
>
>But I do not get to IN APP.
>
>What am I doing wrong?
>
>I tried to jump to 0x08020004 address as it is where hal_reset_vsr is, 
>but still no luck.
>
>ROM startup build copies .data and .bss sections into ram, probably 
>these sections data gets overwritten.
>
>Do I need to shift addresses of SECTION_sram, SECTION_data, SECTION_bss
> 
>in app's memory layout?
>
>Oleg
>
>P.S:
>$ 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
>   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

Oleg

I run a similar configuration on a custom board.
Starting an application located in flash from redboot.

You should read the application start address from the reset vector.
The entry point address is variable because of your linker config.
The only fix reference is the reset vector address.

You have to set the the stack pointer and jump to the address stored at the reset vector entry.

#define HAL_PLF_ARCH_GETRESETVECTOR(__reset,__vector)      \
{                                                       \
    __reset = *((unsigned long*)(__vector+4));          \
    register volatile CYG_ADDRESS __stack_ptr asm("sp");\
    __stack_ptr  = (*((unsigned long*)(__vector)));     \
}

// 'exec' must not a stack variable, 
// because stackpointer could be changed by platform macro
static volatile unsigned long exec; 
HAL_PLF_ARCH_GETRESETVECTOR(exec, 0x08002000);  // use or load address here
((void (*)(void))exec)();

Rainer



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-22 14:40       ` Oleg Uzenkov
@ 2014-10-23  9:55         ` Edgar Grimberg
  2014-10-23 12:53           ` Edgar Grimberg
  0 siblings, 1 reply; 17+ messages in thread
From: Edgar Grimberg @ 2014-10-23  9:55 UTC (permalink / raw)
  To: Oleg Uzenkov; +Cc: eCos Discussion

> (gdb) next
>
> Breakpoint 8, 0x08020000 in ?? ()

Here it looks like you leave the bootloader space and you reach the
start of the application.


> (gdb) next
> Cannot find bounds of current function

This is fine, there are no functions here. Also, you are not debugging
the bootloader anymore, so GDB doesn't know any of the new addresses
to match them with the symbols from the elf file.

> .....
> program just hangs when continued.

It looks like the application has a problem.

>> 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
> ...

Does it display the printf if you continue? If not, this confirms the
theory that the application does not start correctly from its start
address.

Read Rainer's email, too. He might have spotted the problem.

About GBD, if you are debugging an elf that sits on the flash, load
won't flash it for you (unless you have a really smart debugger). But,
a side effect of the load command is that the PC is pointing to the
start address.


Edgar

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-22 19:01     ` Rainer Arndt
@ 2014-10-23 11:50       ` Oleg Uzenkov
  0 siblings, 0 replies; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-23 11:50 UTC (permalink / raw)
  To: Rainer Arndt, Edgar Grimberg, Sergei Gavrikov; +Cc: eCos Discussion

Hi,

Please have a look to this document:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf

on page 21 it says:
"Note This allows a linker to distinguish ARM and Thumb code symbols 
without having to refer to the map. An
ARM symbol will always have an even value, while a Thumb symbol will 
always have an odd value.
However, a linker should strip the discriminating bit from the value 
before using it for relocation."

May be this is why I have:

Entry point address:               0x8000111

entry point of odd value

Cortex-M4 supports only Thumb Mode and the entry point should probably 
be always odd.

My compiler flags:
-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual 
-Wno-write-strings  -mthumb -g -O2 -ffunction-sections -fdata-sections 
-fno-rtti -fno-exceptions -mcpu=cortex-m4

Linker flags:
  -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -nostdlib -mcpu=cortex-m4

Oleg

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-23  9:55         ` Edgar Grimberg
@ 2014-10-23 12:53           ` Edgar Grimberg
  2014-10-23 15:03             ` Oleg Uzenkov
  0 siblings, 1 reply; 17+ messages in thread
From: Edgar Grimberg @ 2014-10-23 12:53 UTC (permalink / raw)
  To: Oleg Uzenkov; +Cc: eCos Discussion

>>> 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
>> ...
>
> Does it display the printf if you continue? If not, this confirms the
> theory that the application does not start correctly from its start
> address.

To gather more evidence, in GDB, can you disassemble the code from
0x08020000 to 0x08020008 ?

(gdb) disas 0x08020000, 0x08020008

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  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
  0 siblings, 2 replies; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-23 15:03 UTC (permalink / raw)
  To: Edgar Grimberg, Rainer Arndt; +Cc: eCos Discussion

Hi again,

At last got some progress! :-)

The jump from the bootloader now works (but with one minor problem. plz 
see below)

I found that the problem was caused by optimisation.
(and it was dumb of me not to pay attention to a warning: optimization 
may eliminate reads and/or writes to register variables)

I should have not used -O option when I use a register variable.

Here is bootloader's code:

#define HAL_PLF_ARCH_GETRESETVECTOR(__reset,__vector)      \
{                                                       \
     __reset = *((unsigned long*)(__vector+4));          \
     register volatile CYG_ADDRESS __stack_ptr asm("sp");\
     __stack_ptr  = (*((unsigned long*)(__vector)));     \
}

static volatile unsigned long exec;

int main (void) {

   diag_printf( "JUMP\n" );

   HAL_PLF_ARCH_GETRESETVECTOR(exec, 0x08020000);

   ((void (*)(void))exec)();

   while (1);

   return 0;
}

Here is app's code:

int main (void) {

   diag_printf( "HELLO1\n" );
   diag_printf( "HELLO2\n" );

   while (1);

     return 0;
}

But there is still some minor problem:

Please have a look at the terminal output:

JUMPC!â–’11=â–’
HELLO2

Notice that instead of "HELLO1" a garbage (C!â–’11=â–’) is printed out.
Where as the next HELLO2 is ok.

It is either something related to diag_print() that was not initialised 
properly.

or may be something to do with thumb mode on Cortex-4?
here:
$ arm-none-eabi-nm -n app.elf | grep hal_reset_vsr
08020984 T hal_reset_vsr

where as exec is (08020984+1):

(gdb) next
28      ((void (*)(void))exec)();
(gdb) print/x exec
$3 = 0x8020985

any ideas?

Thank you very much for you help!!!

Oleg









-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-23 15:03             ` Oleg Uzenkov
@ 2014-10-23 19:25               ` Rainer Arndt
  2014-10-23 21:21               ` Sergei Gavrikov
  1 sibling, 0 replies; 17+ messages in thread
From: Rainer Arndt @ 2014-10-23 19:25 UTC (permalink / raw)
  To: Oleg Uzenkov, Edgar Grimberg; +Cc: eCos Discussion


>Please have a look at the terminal output:
>
>JUMPC!â–’11=â–’
>HELLO2
>
>Notice that instead of "HELLO1" a garbage (C!â–’11=â–’) is printed out.
>Where as the next HELLO2 is ok.
>
>It is either something related to diag_print() that was not initialised
>properly.
>any ideas?
>
>Thank you very much for you help!!!
>
>Oleg

Oleg,

remember the HAL initialisation code is always part of your application.
Depending on your eCos configuration, the serial device and its tx port is initialized by the bootloader and again by your application.

Rainer


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  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
  1 sibling, 1 reply; 17+ messages in thread
From: Sergei Gavrikov @ 2014-10-23 21:21 UTC (permalink / raw)
  To: Oleg Uzenkov; +Cc: eCos Discussion

On Thu, 23 Oct 2014, Oleg Uzenkov wrote:

> At last got some progress! :-)

Congrats!

[snip]

>   HAL_PLF_ARCH_GETRESETVECTOR(exec, 0x08020000);
                                           ^^^^^
Oleg, you reserve 128K for "small custom bootloader", 128K is more than
enough to use RedBoot. If you can donate 128K for boot-loader then use
RedBoot.  I am sure that RedBoot can run and your "ROMROM" applications.
If standard RedBoot lacks some behaviors, just provide new functionality
with custom RedBoot command(s) FYI: this code can be part platform HAL.

Paraphrasing  Greenspun's Tenth Rule, Any custom boot-loader for eCos
will contain an ad hoc, informally-specified, bug-ridden, implementation
of half of RedBoot :-)

I assure you if you can donate 128K for your own bootstrap code then
using RedBoot will save your time and efforts.

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-23 21:21               ` Sergei Gavrikov
@ 2014-10-24  7:44                 ` Oleg Uzenkov
  2014-10-24  8:36                   ` Sergei Gavrikov
  0 siblings, 1 reply; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-24  7:44 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: eCos Discussion

Hi,

I agree!

Redboot is a great piece of software. It is just I found that when you 
enable some important features like FIS support, Redboot reserves extra 
space in RAM memory.
The size of this reserved extra space in RAM equals to the size of the 
largest section size in Flash. In case of stm32f407 it is 128KB. 
Internal RAM is 128KB. As John Dallaway pointed out there is very little 
sense in using Redboot without enough of external RAM on stm32f4 
devices. For example for Kinetis it is a different story, the flash 
sections are uniform and quite small.

For small systems external RAM chip significantly adds up to the cost of 
a device.

Best wishes,
Oleg
> On Thu, 23 Oct 2014, Oleg Uzenkov wrote:
>
>> At last got some progress! :-)
> Congrats!
>
> [snip]
>
>>    HAL_PLF_ARCH_GETRESETVECTOR(exec, 0x08020000);
>                                             ^^^^^
> Oleg, you reserve 128K for "small custom bootloader", 128K is more than
> enough to use RedBoot. If you can donate 128K for boot-loader then use
> RedBoot.  I am sure that RedBoot can run and your "ROMROM" applications.
> If standard RedBoot lacks some behaviors, just provide new functionality
> with custom RedBoot command(s) FYI: this code can be part platform HAL.
>
> Paraphrasing  Greenspun's Tenth Rule, Any custom boot-loader for eCos
> will contain an ad hoc, informally-specified, bug-ridden, implementation
> of half of RedBoot :-)
>
> I assure you if you can donate 128K for your own bootstrap code then
> using RedBoot will save your time and efforts.
>
> Sergei
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-24  7:44                 ` Oleg Uzenkov
@ 2014-10-24  8:36                   ` Sergei Gavrikov
  2014-10-24  9:13                     ` Oleg Uzenkov
  2014-10-24  9:13                     ` Sergei Gavrikov
  0 siblings, 2 replies; 17+ messages in thread
From: Sergei Gavrikov @ 2014-10-24  8:36 UTC (permalink / raw)
  To: Oleg Uzenkov; +Cc: eCos Discussion

On Fri, 24 Oct 2014, Oleg Uzenkov wrote:

> Redboot is a great piece of software. It is just I found that when you
> enable some important features like FIS support, Redboot reserves
> extra space in RAM memory.
> The size of this reserved extra space in RAM equals to the size of the
> largest section size in Flash. In case of stm32f407 it is 128KB.
> Internal RAM is 128KB. As John Dallaway pointed out there is very
> little sense in using Redboot without enough of external RAM on
> stm32f4 devices. For example for Kinetis it is a different story, the
> flash sections are uniform and quite small.
> 
> For small systems external RAM chip significantly adds up to the cost
> of a device.
 
I understand John's point and agree with him. But, he told about using
debug infrastructure of RedBoot (debugging eCos applications in RAM).
But, RedBoot is *debug* and *bootstrap* environment for eCos. I pointed
on another side of RedBoot, *bootstrap*. You can quite run eCos [ROM]
builds from FIS. Those [ROM] applications may utilize all RAM (128K +
64K) on your target. On start ROM application just does overlay RedBoot
memory.  You saw that yesterday with Rainer's approach (exec). If you
cannot manage run [ROM] applications with RedBoot command 'go', just
implement one new command for RedBoot, e.g. 'xip' (as RedBoot already
uses 'exec' name to run Linux kernel). RedBoot will let you to use
FLASH I/O, load any images, use start scripts, etc., etc. Of course it
is my opinion only.

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-24  8:36                   ` Sergei Gavrikov
@ 2014-10-24  9:13                     ` Oleg Uzenkov
  2014-10-24  9:13                     ` Sergei Gavrikov
  1 sibling, 0 replies; 17+ messages in thread
From: Oleg Uzenkov @ 2014-10-24  9:13 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: eCos Discussion


Thanks,

I will give it a try with ROM builds.
> On Fri, 24 Oct 2014, Oleg Uzenkov wrote:
>
>> Redboot is a great piece of software. It is just I found that when you
>> enable some important features like FIS support, Redboot reserves
>> extra space in RAM memory.
>> The size of this reserved extra space in RAM equals to the size of the
>> largest section size in Flash. In case of stm32f407 it is 128KB.
>> Internal RAM is 128KB. As John Dallaway pointed out there is very
>> little sense in using Redboot without enough of external RAM on
>> stm32f4 devices. For example for Kinetis it is a different story, the
>> flash sections are uniform and quite small.
>>
>> For small systems external RAM chip significantly adds up to the cost
>> of a device.
>   
> I understand John's point and agree with him. But, he told about using
> debug infrastructure of RedBoot (debugging eCos applications in RAM).
> But, RedBoot is *debug* and *bootstrap* environment for eCos. I pointed
> on another side of RedBoot, *bootstrap*. You can quite run eCos [ROM]
> builds from FIS.

FIS support requires 128KB of ram on stm32.

> Those [ROM] applications may utilize all RAM (128K +
> 64K) on your target. On start ROM application just does overlay RedBoot
> memory.  You saw that yesterday with Rainer's approach (exec). If you
> cannot manage run [ROM] applications with RedBoot command 'go', just
> implement one new command for RedBoot, e.g. 'xip' (as RedBoot already
> uses 'exec' name to run Linux kernel).

As far as I understand, 'go' command should work in theory as it sets 
program counter (pc) to the address of Entry point (not sure about stack 
pointer).

To make a jump  we need to set stack pointer and program counter. And 
this can be implemented inside a new 'xip' command.

> RedBoot will let you to use
> FLASH I/O, load any images, use start scripts, etc., etc. Of course it
> is my opinion only.
>
> Sergei


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [ECOS] small custom bootloader to start an app stored in flash
  2014-10-24  8:36                   ` Sergei Gavrikov
  2014-10-24  9:13                     ` Oleg Uzenkov
@ 2014-10-24  9:13                     ` Sergei Gavrikov
  1 sibling, 0 replies; 17+ messages in thread
From: Sergei Gavrikov @ 2014-10-24  9:13 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: eCos Discussion

On Fri, 24 Oct 2014, Sergei Gavrikov wrote:

> On Fri, 24 Oct 2014, Oleg Uzenkov wrote:
> 
> > Redboot is a great piece of software. It is just I found that when you
> > enable some important features like FIS support, Redboot reserves
> > extra space in RAM memory.
> > The size of this reserved extra space in RAM equals to the size of the
> > largest section size in Flash. In case of stm32f407 it is 128KB.
> > Internal RAM is 128KB. As John Dallaway pointed out there is very
> > little sense in using Redboot without enough of external RAM on
> > stm32f4 devices. For example for Kinetis it is a different story, the
> > flash sections are uniform and quite small.
> > 
> > For small systems external RAM chip significantly adds up to the cost
> > of a device.
>  
> I understand John's point and agree with him. But, he told about using
> debug infrastructure of RedBoot (debugging eCos applications in RAM).
> But, RedBoot is *debug* and *bootstrap* environment for eCos. I pointed
> on another side of RedBoot, *bootstrap*. You can quite run eCos [ROM]
> builds from FIS. Those [ROM] applications may utilize all RAM (128K +
> 64K) on your target. On start ROM application just does overlay RedBoot
> memory.  You saw that yesterday with Rainer's approach (exec). If you
> cannot manage run [ROM] applications with RedBoot command 'go', just
> implement one new command for RedBoot, e.g. 'xip' (as RedBoot already
> uses 'exec' name to run Linux kernel). RedBoot will let you to use
> FLASH I/O, load any images, use start scripts, etc., etc. Of course it
> is my opinion only.

For clarity. If you have no idea how to burn big images on FLASH using
only 128K RAM (and it is possible and without RedBoot load-into-flash
feature which needs extra memory, 128K) see below a "way". Split source
binary on 64K chunks, gzip the chunks (you told about GPRS modem) and
upload those chunks with RedBoot. After uploading the next part write it
on FLASH with 0x10000 offset.

Host

  split -b 64K app.bin
  gzip xa*

Target

  load -m x -d -r ...
  fis write ...

Of course, the process can be automated with Expect.

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2014-10-24  9:13 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-21  8:27 [ECOS] small custom bootloader to start an app stored in flash 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
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                     ` Oleg Uzenkov
2014-10-24  9:13                     ` Sergei Gavrikov
2014-10-22 19:01     ` Rainer Arndt
2014-10-23 11:50       ` Oleg Uzenkov

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).