small custom bootloader to start an app stored in flash

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

small custom bootloader to start an app stored in flash

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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Edgar Grimberg-2
In reply to this post by Oleg Uzenkov
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Oleg Uzenkov
In reply to this post by Oleg Uzenkov
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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Edgar Grimberg-2
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Oleg Uzenkov

>> 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 | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Rainer Arndt
In reply to this post by Oleg Uzenkov
Am 22. Oktober 2014 13:08:33 MESZ, schrieb Oleg Uzenkov <[hidden email]>:

>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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Edgar Grimberg-2
In reply to this post by Oleg Uzenkov
> (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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Oleg Uzenkov
In reply to this post by Rainer Arndt
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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Edgar Grimberg-2
In reply to this post by Edgar Grimberg-2
>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Rainer Arndt

>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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Sergei Gavrikov-4
In reply to this post by Oleg Uzenkov
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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Sergei Gavrikov-4
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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Sergei Gavrikov-4
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

Reply | Threaded
Open this post in threaded view
|

Re: small custom bootloader to start an app stored in flash

Oleg Uzenkov
In reply to this post by Sergei Gavrikov-4

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