[ECOS] redboot on STM32f4-discovery board

[ECOS] redboot on STM32f4-discovery board

[Oleg Uzenkov]

Hi,

I am working with eCos on STM32f4-discovery board.

I would like to build a redboot loader that could choose and load 
binaries (eCos+app) stored in internal flash at power on.

The eCos port for STM32f4-discovery has got a redboot option under 
Packages list in Templates. However it seems to be very minimalistic and 
also not functional. Also there is no specific configuration file like 
redboot_ROM.ecm.

Please, could you give me directions as to making a functional redboot 
loader for STM32f4-discovery board.

Would it make sense to build redboot for stm32x0g_eval board (redboot 
seems to be working) and adapt it for STM32f4-discovery board?

I would appreciate any input on this.

Thanks in advance.

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

[ECOS] Re: redboot on STM32f4-discovery board

[John Dallaway]

Hi Oleg

On 02/10/14 09:47, Oleg Uzenkov wrote:

> I am working with eCos on STM32f4-discovery board.
> 
> I would like to build a redboot loader that could choose and load
> binaries (eCos+app) stored in internal flash at power on.
> 
> The eCos port for STM32f4-discovery has got a redboot option under
> Packages list in Templates. However it seems to be very minimalistic and
> also not functional. Also there is no specific configuration file like
> redboot_ROM.ecm.
> 
> Please, could you give me directions as to making a functional redboot
> loader for STM32f4-discovery board.
> 
> Would it make sense to build redboot for stm32x0g_eval board (redboot
> seems to be working) and adapt it for STM32f4-discovery board?
> 
> I would appreciate any input on this.

To be clear, there is no support for RedBoot in the STM32F4-Discovery
platform HAL at present. The STM32F4-Discovery board offers only 128KiB
of contiguous on-chip RAM, so loading applications into RAM prior to
execution would limit the size of your applications quite considerably.
RedBoot would also consume some of the available RAM for its own data
structures.

If you are still interested in using RedBoot to load and launch your
applications, you will need to add the following to the
STM32F4-Discovery platform HAL package:

a) CDL items and memory layout files for RAM startup
b) CDL items for behaving as a ROM monitor and for working with a ROM
   monitor
c) RedBoot-specific CDL items and data structures

You will find examples of all the above in the STM32x0G_EVAL platform
HAL package, but keep in mind that the STM32x0G_EVAL boards feature
external RAM. The naming of memory regions and startup types is
therefore different. The STM32x0G_EVAL "ROMINT" and "SRAM" startup types
are broadly equivalent to the STM32F4-Discovery "ROM" and (proposed)
"RAM" startup types respectively.

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

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

Re: [ECOS] Re: redboot on STM32f4-discovery board

["Ilija Kocho [Илија Кочо]"]

On 03.10.2014 13:40, John Dallaway wrote:
> Hi Oleg
>
> On 02/10/14 09:47, Oleg Uzenkov wrote:
>
>> I am working with eCos on STM32f4-discovery board.
>>
>> I would like to build a redboot loader that could choose and load
>> binaries (eCos+app) stored in internal flash at power on.
>>
>> The eCos port for STM32f4-discovery has got a redboot option under
>> Packages list in Templates. However it seems to be very minimalistic and
>> also not functional. Also there is no specific configuration file like
>> redboot_ROM.ecm.
>>
>> Please, could you give me directions as to making a functional redboot
>> loader for STM32f4-discovery board.
>>
>> Would it make sense to build redboot for stm32x0g_eval board (redboot
>> seems to be working) and adapt it for STM32f4-discovery board?
>>
>> I would appreciate any input on this.
> To be clear, there is no support for RedBoot in the STM32F4-Discovery
> platform HAL at present. The STM32F4-Discovery board offers only 128KiB
> of contiguous on-chip RAM, so loading applications into RAM prior to
> execution would limit the size of your applications quite considerably.
> RedBoot would also consume some of the available RAM for its own data
> structures.
>
> If you are still interested in using RedBoot to load and launch your
> applications, you will need to add the following to the
> STM32F4-Discovery platform HAL package:
>
> a) CDL items and memory layout files for RAM startup
> b) CDL items for behaving as a ROM monitor and for working with a ROM
>    monitor
> c) RedBoot-specific CDL items and data structures
>
> You will find examples of all the above in the STM32x0G_EVAL platform
> HAL package, but keep in mind that the STM32x0G_EVAL boards feature
> external RAM. The naming of memory regions and startup types is
> therefore different. The STM32x0G_EVAL "ROMINT" and "SRAM" startup types
> are broadly equivalent to the STM32F4-Discovery "ROM" and (proposed)
> "RAM" startup types respectively.

In addition, for example of RedBoot on a platform with only internal RAM
you can look at Kinetis.

Ilija

>
> I hope this helps...
>
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
>


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

Re: [ECOS] Re: redboot on STM32f4-discovery board

[Oleg Uzenkov]

Hello, John, Ilija,

Thanks for your help!

I will study in depth STM32x0G_EVAL and Kinetis platform HAL packages.

My main goal is to port and use redboot on my own custom board which is 
similar to STM32f4-discovery board (stm32f407VE processor, no external 
ram, 512KB of internal flash, 128KiB  of ram). The custom board has got 
sdcard (with FAT32) though. Redboot should be responsible for loading a 
binary stored in sdcard.

The general steps, it seems to me I need to take, are as follows:

1) add cdl items you mentioned in the previous mail into the board's HAL 
package ( + all what is needed to work with sdcard) -> build redboot.bin
2) load redboot.bin (built as "ROM" startup type)  into internal flash 
at 0x08000000
3) place app.bin file onto sdcard (image need to be built with "RAM" 
startup type)
4) on reset redboot mounts sdcard -> selects a binary and loads it into 
internal flash (at address not overlapping redboot)
5) need to copy app's code to ram for execution and run it (do not know 
how to, probably need startup code?)

Please, could you correct me if I am wrong in the general understanding.

I very much appreciate your help.

Oleg

> On 03.10.2014 13:40, John Dallaway wrote:
>> Hi Oleg
>>
>> On 02/10/14 09:47, Oleg Uzenkov wrote:
>>
>>> I am working with eCos on STM32f4-discovery board.
>>>
>>> I would like to build a redboot loader that could choose and load
>>> binaries (eCos+app) stored in internal flash at power on.
>>>
>>> The eCos port for STM32f4-discovery has got a redboot option under
>>> Packages list in Templates. However it seems to be very minimalistic and
>>> also not functional. Also there is no specific configuration file like
>>> redboot_ROM.ecm.
>>>
>>> Please, could you give me directions as to making a functional redboot
>>> loader for STM32f4-discovery board.
>>>
>>> Would it make sense to build redboot for stm32x0g_eval board (redboot
>>> seems to be working) and adapt it for STM32f4-discovery board?
>>>
>>> I would appreciate any input on this.
>> To be clear, there is no support for RedBoot in the STM32F4-Discovery
>> platform HAL at present. The STM32F4-Discovery board offers only 128KiB
>> of contiguous on-chip RAM, so loading applications into RAM prior to
>> execution would limit the size of your applications quite considerably.
>> RedBoot would also consume some of the available RAM for its own data
>> structures.
>>
>> If you are still interested in using RedBoot to load and launch your
>> applications, you will need to add the following to the
>> STM32F4-Discovery platform HAL package:
>>
>> a) CDL items and memory layout files for RAM startup
>> b) CDL items for behaving as a ROM monitor and for working with a ROM
>>     monitor
>> c) RedBoot-specific CDL items and data structures
>>
>> You will find examples of all the above in the STM32x0G_EVAL platform
>> HAL package, but keep in mind that the STM32x0G_EVAL boards feature
>> external RAM. The naming of memory regions and startup types is
>> therefore different. The STM32x0G_EVAL "ROMINT" and "SRAM" startup types
>> are broadly equivalent to the STM32F4-Discovery "ROM" and (proposed)
>> "RAM" startup types respectively.
> In addition, for example of RedBoot on a platform with only internal RAM
> you can look at Kinetis.
>
> Ilija
>
>> I hope this helps...
>>
>> John Dallaway
>> eCos maintainer
>> http://www.dallaway.org.uk/john
>>
>


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

Re: [ECOS] Re: redboot on STM32f4-discovery board

["Ilija Kocho [Илија Кочо]"]

On 05.10.2014 10:32, Oleg Uzenkov wrote:
> Hello, John, Ilija,
>
> Thanks for your help!
>
> I will study in depth STM32x0G_EVAL and Kinetis platform HAL packages.
>
> My main goal is to port and use redboot on my own custom board which
> is similar to STM32f4-discovery board (stm32f407VE processor, no
> external ram, 512KB of internal flash, 128KiB  of ram). The custom
> board has got sdcard (with FAT32) though. Redboot should be
> responsible for loading a binary stored in sdcard.
>
> The general steps, it seems to me I need to take, are as follows:
>
> 1) add cdl items you mentioned in the previous mail into the board's
> HAL package ( + all what is needed to work with sdcard) -> build
> redboot.bin
> 2) load redboot.bin (built as "ROM" startup type)  into internal flash
> at 0x08000000
> 3) place app.bin file onto sdcard (image need to be built with "RAM"
> startup type)

You may consider creation of FLASH startup type.
Here http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623 I started a
discussion on this subject, I hope this thread triggers us to a
conclusion :).

Ilija

> 4) on reset redboot mounts sdcard -> selects a binary and loads it
> into internal flash (at address not overlapping redboot)
> 5) need to copy app's code to ram for execution and run it (do not
> know how to, probably need startup code?)
>
> Please, could you correct me if I am wrong in the general understanding.
>
> I very much appreciate your help.
>
> Oleg
>
>> On 03.10.2014 13:40, John Dallaway wrote:
>>> Hi Oleg
>>>
>>> On 02/10/14 09:47, Oleg Uzenkov wrote:
>>>
>>>> I am working with eCos on STM32f4-discovery board.
>>>>
>>>> I would like to build a redboot loader that could choose and load
>>>> binaries (eCos+app) stored in internal flash at power on.
>>>>
>>>> The eCos port for STM32f4-discovery has got a redboot option under
>>>> Packages list in Templates. However it seems to be very
>>>> minimalistic and
>>>> also not functional. Also there is no specific configuration file like
>>>> redboot_ROM.ecm.
>>>>
>>>> Please, could you give me directions as to making a functional redboot
>>>> loader for STM32f4-discovery board.
>>>>
>>>> Would it make sense to build redboot for stm32x0g_eval board (redboot
>>>> seems to be working) and adapt it for STM32f4-discovery board?
>>>>
>>>> I would appreciate any input on this.
>>> To be clear, there is no support for RedBoot in the STM32F4-Discovery
>>> platform HAL at present. The STM32F4-Discovery board offers only 128KiB
>>> of contiguous on-chip RAM, so loading applications into RAM prior to
>>> execution would limit the size of your applications quite considerably.
>>> RedBoot would also consume some of the available RAM for its own data
>>> structures.
>>>
>>> If you are still interested in using RedBoot to load and launch your
>>> applications, you will need to add the following to the
>>> STM32F4-Discovery platform HAL package:
>>>
>>> a) CDL items and memory layout files for RAM startup
>>> b) CDL items for behaving as a ROM monitor and for working with a ROM
>>>     monitor
>>> c) RedBoot-specific CDL items and data structures
>>>
>>> You will find examples of all the above in the STM32x0G_EVAL platform
>>> HAL package, but keep in mind that the STM32x0G_EVAL boards feature
>>> external RAM. The naming of memory regions and startup types is
>>> therefore different. The STM32x0G_EVAL "ROMINT" and "SRAM" startup
>>> types
>>> are broadly equivalent to the STM32F4-Discovery "ROM" and (proposed)
>>> "RAM" startup types respectively.
>> In addition, for example of RedBoot on a platform with only internal RAM
>> you can look at Kinetis.
>>
>> Ilija
>>
>>> I hope this helps...
>>>
>>> John Dallaway
>>> eCos maintainer
>>> http://www.dallaway.org.uk/john
>>>
>>
>
>


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

[ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

Hello All,

I am working with redboot on stm3240g_eval board.

I need redboot to load an image from flash for execution but it does not 
work for me yet.

These are my steps:

1. Build app.elf for ROM startup and test app.bin that it works on the 
board. It does, I can see text in terminal when it starts. So the app works.

code:
int main (void)
{
    diag_printf( "HELLO\n" );
    while (1);
    return 0;
}

2. Build redboot for ROM startup and flash it at 0x08000000. It works as 
well.

RedBoot(tm) bootstrap and debug environment [ROM]
...
Platform: ST STM3240G-EVAL (Cortex-M4)
RAM: 0x64000000-0x64200000 [0x64005d30-0x641dd000 available]
      0x20000000-0x2001f000 [0x20000000-0x2001f000 available]
      0x10000000-0x10010000 [0x10000000-0x10010000 available]
FLASH: 0x08000000-0x080fffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 7 x 
0x20000 blocks
RedBoot>

3. Do "fis init -f"  All is well too.

RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0x08020000-0x080dffff: ......
... Erase from 0x080e0000-0x080fffff: .
... Program from 0x641e0000-0x64200000 to 0x080e0000: .
RedBoot>

4. Build app.elf now for RAM startup.

5. Transfer app.elf to redboot via serial xmodem
I transfer it to external ram first.

RedBoot> load -r -m xmodem -b 0x64010000

6. Create fis entry for the app

RedBoot> fis create -b 0x64010000 -f 0x08040000 app

now see if it is there: all is well ...

RedBoot> fis list
Name                   FLASH addr  Mem addr    Length      Entry point
RedBoot               0x08000000  0x08000000  0x00020000 0x00000000
app                      0x08040000  0x64010000  0x00020000 0x64010000
FIS directory        0x080E0000  0x080E0000  0x0001F000 0x00000000
RedBoot config    0x080FF000  0x080FF000  0x00001000  0x00000000

7. Load app image and start it

RedBoot> fis load app
RedBoot> go
$T080f:00000164;0d:e8cf1d64;

I do not know what that means. Probably memory corruption.

Can you see what I am doing wrong?

I would appreciate any help on this, as I am running out of ideas now.

Thanks in advance.

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Edgar Grimberg]

> RedBoot> go
> $T080f:00000164;0d:e8cf1d64;
>
> I do not know what that means. Probably memory corruption.

Try to connect gdb on the host machine via the serial port to the
target, and try debugging. The string you are seeing is gdbserver on
the target trying to say something to gdb client.

https://sourceware.org/gdb/onlinedocs/gdb/Connecting.html

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

Thanks Edgar.

I have redboot for ROM and app.elf for RAM

I do the following and it works:

arm-none-eabi-gdb -b 115200 app.elf
(gdb) target remote /dev/ttyUSB0
GNU gdb (Sourcery G++ Lite 2011.03-42) 7.2.50.20100908-cvs
....
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
Ignoring packet error, continuing...
Ignoring packet error, continuing...
0x00008000 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x64008000
Loading section .ARM.extab, size 0x3c lma 0x64008008
Loading section .ARM.exidx, size 0xc8 lma 0x64008048
Loading section .text, size 0x595c lma 0x64008110
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Loading section .rodata, size 0x204 lma 0x6400da70
Loading section .data, size 0x2a8 lma 0x6400dc80
Ignoring packet error, continuing...
Start address 0x64008110, load size 24340
Transfer rate: 81 bytes/sec, 283 bytes/write.
(gdb) continue
Continuing.
HELLO


However, it does not work from redboot.

I have a feeling i did not specify correct addresses with:

load -r -m xmodem -b 0x64010000

fis create -b 0x64010000 -f 0x08040000 app

fis load app

I did not specify Entry Point addresse either (not sure with the values)

Please could you check the steps from the previous mail. Did I do 
everything in the correct way?

Oleg


>> RedBoot> go
>> $T080f:00000164;0d:e8cf1d64;
>>
>> I do not know what that means. Probably memory corruption.
> Try to connect gdb on the host machine via the serial port to the
> target, and try debugging. The string you are seeing is gdbserver on
> the target trying to say something to gdb client.
>
> https://sourceware.org/gdb/onlinedocs/gdb/Connecting.html
>
> Regards,
> 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

Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov]

On Thu, 9 Oct 2014, Oleg Uzenkov wrote:

> 4. Build app.elf now for RAM startup.

First, check that application runs as expected in GDB (reset board)

  <cross>-gdb -q -nx app.elf
  (gdb) target remote <serial_device>
  (gdb) load
  (gdb) continue

If you see the expected output, then try the below as

> 5. Transfer app.elf to redboot via serial xmodem
> I transfer it to external ram first.
>
> RedBoot> load -r -m xmodem -b 0x64010000

Do not use -r(aw), and -b(ase) switches if you load *ELF* images. If you
use serial port, load ELFs as

  RedBoot> load -m x

> 6. Create fis entry for the app
>
> RedBoot> fis create -b 0x64010000 -f 0x08040000 app

Again, no need to force base address, if the previous command was
`load' (load of ELF). Just type

  RedBoot> fis create <name>

Thus, do not use odd switches if you load and save ELFs on FIS, do

  RedBoot> load -m x
  RedBoot> fis create <name>
  RedBoot> fis load <name>
  RedBoot> go

Also I suggest to use standard eCos tests (RAM builds) as the first
eCos applications, i.e. `make tests' and play with them (load and go).

HTH

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

Thank you very much, Sergei!

the way you described works just fine:

   RedBoot> load -m x
   RedBoot> fis create app
   RedBoot> fis load app
   RedBoot> go

the app gets executed correctly! Huray!

ELF files are quite large, what is the preferred format for an image to 
be passed to redboot?
what "load" and "fis create" command look like?

Oleg



> On Thu, 9 Oct 2014, Oleg Uzenkov wrote:
>
>> 4. Build app.elf now for RAM startup.
> First, check that application runs as expected in GDB (reset board)
>
>    <cross>-gdb -q -nx app.elf
>    (gdb) target remote <serial_device>
>    (gdb) load
>    (gdb) continue
>
> If you see the expected output, then try the below as
>
>> 5. Transfer app.elf to redboot via serial xmodem
>> I transfer it to external ram first.
>>
>> RedBoot> load -r -m xmodem -b 0x64010000
> Do not use -r(aw), and -b(ase) switches if you load *ELF* images. If you
> use serial port, load ELFs as
>
>    RedBoot> load -m x
>
>> 6. Create fis entry for the app
>>
>> RedBoot> fis create -b 0x64010000 -f 0x08040000 app
> Again, no need to force base address, if the previous command was
> `load' (load of ELF). Just type
>
>    RedBoot> fis create <name>
>
> Thus, do not use odd switches if you load and save ELFs on FIS, do
>
>    RedBoot> load -m x
>    RedBoot> fis create <name>
>    RedBoot> fis load <name>
>    RedBoot> go
>
> Also I suggest to use standard eCos tests (RAM builds) as the first
> eCos applications, i.e. `make tests' and play with them (load and go).
>
> HTH
>
> 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

Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov]

On Thu, 9 Oct 2014, Oleg Uzenkov wrote:

> Thank you very much, Sergei!
>
> the way you described works just fine:
>
>   RedBoot> load -m x
>   RedBoot> fis create app
>   RedBoot> fis load app
>   RedBoot> go
>
> the app gets executed correctly! Huray!
>
> ELF files are quite large, what is the preferred format for an image
> to be passed to redboot?  what "load" and "fis create" command look
> like?

**Roughly** speaking, you save .text segment in FLASH (adjusted to flash
block erase size), you save not ELF image! So, do not mess with
binaries. Also `load' command does not carry whole ELF image into RAM,
but .text segment with a few other segments.

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

[ECOS] redboot on STM32f4-discovery board

[Oleg Uzenkov]

Hello All,

I have tried to run redboot on a custom board (very similar to 
STM32f4-discovery board, so let's say that we have discovery in question).

I do understand that there is a little point to run redboot on a board 
without external RAM (due to memory limitations).

At this moment, I am not looking at loading and storing images via 
redboot (this would be the next step, the images will be small).

I just would like to get redboot working on a board without external RAM.

These are my findings so far:

1. I built redboot for ROM startup (applied relevant adjustings from 
stm3240g_eval's  redboot_rom.ecm)

2. flashed the board with redboot at 0x08000000

3.
when CYGOPT_REDBOOT_FIS == 0 redboot loads, but is very unstable, can 
stop working any time... But, without Flash Image System I do not see 
how to use redboot to load and store and run images.

when CYGOPT_REDBOOT_FIS == 1  redboot hangs.  It happens when 
do_flash_init() runs (problem in memcpy , probably illigal memory access)

A question, can actually redboot work without external ram?

If yes, how to fit it properly? (the board has stm32f407VE with 128+64 
KB of internal ram, 512KB internal flash)

I would appreciate any input on this.

Oleg



> On 03.10.2014 13:40, John Dallaway wrote:
>> Hi Oleg
>>
>> On 02/10/14 09:47, Oleg Uzenkov wrote:
>>
>>> I am working with eCos on STM32f4-discovery board.
>>>
>>> I would like to build a redboot loader that could choose and load
>>> binaries (eCos+app) stored in internal flash at power on.
>>>
>>> The eCos port for STM32f4-discovery has got a redboot option under
>>> Packages list in Templates. However it seems to be very minimalistic and
>>> also not functional. Also there is no specific configuration file like
>>> redboot_ROM.ecm.
>>>
>>> Please, could you give me directions as to making a functional redboot
>>> loader for STM32f4-discovery board.
>>>
>>> Would it make sense to build redboot for stm32x0g_eval board (redboot
>>> seems to be working) and adapt it for STM32f4-discovery board?
>>>
>>> I would appreciate any input on this.
>> To be clear, there is no support for RedBoot in the STM32F4-Discovery
>> platform HAL at present. The STM32F4-Discovery board offers only 128KiB
>> of contiguous on-chip RAM, so loading applications into RAM prior to
>> execution would limit the size of your applications quite considerably.
>> RedBoot would also consume some of the available RAM for its own data
>> structures.
>>
>> If you are still interested in using RedBoot to load and launch your
>> applications, you will need to add the following to the
>> STM32F4-Discovery platform HAL package:
>>
>> a) CDL items and memory layout files for RAM startup
>> b) CDL items for behaving as a ROM monitor and for working with a ROM
>>     monitor
>> c) RedBoot-specific CDL items and data structures
>>
>> You will find examples of all the above in the STM32x0G_EVAL platform
>> HAL package, but keep in mind that the STM32x0G_EVAL boards feature
>> external RAM. The naming of memory regions and startup types is
>> therefore different. The STM32x0G_EVAL "ROMINT" and "SRAM" startup types
>> are broadly equivalent to the STM32F4-Discovery "ROM" and (proposed)
>> "RAM" startup types respectively.
> In addition, for example of RedBoot on a platform with only internal RAM
> you can look at Kinetis.
>
> Ilija
>
>> I hope this helps...
>>
>> John Dallaway
>> eCos maintainer
>> http://www.dallaway.org.uk/john
>>
>


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

[ECOS] Re: redboot on STM32f4-discovery board

[John Dallaway]

Hi Oleg

On 09/10/14 16:48, Oleg Uzenkov wrote:

> I have tried to run redboot on a custom board (very similar to
> STM32f4-discovery board, so let's say that we have discovery in question).

[ snip ]

> I just would like to get redboot working on a board without external RAM.
> 
> These are my findings so far:
> 
> 1. I built redboot for ROM startup (applied relevant adjustings from
> stm3240g_eval's  redboot_rom.ecm)
> 
> 2. flashed the board with redboot at 0x08000000
> 
> 3.
> when CYGOPT_REDBOOT_FIS == 0 redboot loads, but is very unstable, can
> stop working any time... But, without Flash Image System I do not see
> how to use redboot to load and store and run images.
> 
> when CYGOPT_REDBOOT_FIS == 1  redboot hangs.  It happens when
> do_flash_init() runs (problem in memcpy , probably illigal memory access)
> 
> A question, can actually redboot work without external ram?
> 
> If yes, how to fit it properly? (the board has stm32f407VE with 128+64
> KB of internal ram, 512KB internal flash)

Consider the output of RedBoot on STM3240G-EVAL (from your earlier message):

> RedBoot(tm) bootstrap and debug environment [ROM]
> ...
> Platform: ST STM3240G-EVAL (Cortex-M4)
> RAM: 0x64000000-0x64200000 [0x64005d30-0x641dd000 available]
>      0x20000000-0x2001f000 [0x20000000-0x2001f000 available]
>      0x10000000-0x10010000 [0x10000000-0x10010000 available]
> FLASH: 0x08000000-0x080fffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 7 x 0x20000 blocks
> RedBoot> 

This shows that RedBoot is using 0x5d30 bytes of external RAM with FIS
enabled. If you have ported RedBoot to your custom board correctly, I
would expect it to report internal RAM usage similar, but not identical,
to the following:

> RAM: 0x20000000-0x2001f000 [0x20005d30-0x2001f000 available]

Is that what you are observing?

So RedBoot should fit it available RAM quite easily.

I would concentrate on tracking down the reliability issue when RedBoot
is configured without the FIS first. Once you have a stable RedBoot
without the FIS, you can then try enabling the FIS.

I hope this helps....

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john


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

Re: [ECOS] redboot on STM32f4-discovery board

[Sergei Gavrikov]

On Thu, 9 Oct 2014, Oleg Uzenkov wrote:

> But, without Flash Image System I do not see how to use redboot to
> load and store and run images.

Even for builds (CYGOPT_REDBOOT_FIS == 0) you can manage FLASH using
absolute FLASH addresses and FIS sub-commands: erase and write.

When you make RedBoot work smoothly on your target, then you can try to
load images directly to FLASH if you enable

  cdl_option CYGBLD_REDBOOT_LOAD_INTO_FLASH {
      user_value 1
  };

eCos is designed with XIP (eXecute In Place) in mind and you can use
RedBoot 'go' command to execute ROM image from specified place of FLASH.

For simple applications it would be enough just to shift *rom* ORIGIN
address and *rom_vectors* address in `target.ld' file and re-link ROM
application, then with the option above it is possible to load and run
such ROM image as

  load -m <protocol>
  go

I call that it worked on my target (load-into-flash-and-go). However,
you need to inspect and may be fix HAL startup files for such "FLASH"
builds.

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

>
> ELF files are quite large, what is the preferred format for an image
> to be passed to redboot?  what "load" and "fis create" command look
> like?
> **Roughly** speaking, you save .text segment in FLASH (adjusted to flash
> block erase size), you save not ELF image! So, do not mess with
> binaries. Also `load' command does not carry whole ELF image into RAM,
> but .text segment with a few other segments.
The thing is:
I will need to work with files (new firmware should arrive to sdcard on 
the board through ftp in a main app). I want redboot to pick a new image 
up from sdcard at reset.
Extracting sections from received ELF file and transferring them to 
redboot is more of a manual work.
So, I think I am kind of stuck with ELF files.

So I am thinking:

* Should I load compressed ELF file (gzip) with -d switch?

* Should I load SREC file (they are usually smaller than ELF)?

* Should I save executable sections and store them in a file. Transfer 
that file to sdcard for redboot to pick it up at reset.
(nor sure how to do it actually)

* Can I actually load a .bin (image in binary format)?

Thanks.
Oleg


> 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

Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov]

On Fri, 10 Oct 2014, Oleg Uzenkov wrote:

> > 
> > ELF files are quite large, what is the preferred format for an image
> > to be passed to redboot?  what "load" and "fis create" command look
> > like?
> > **Roughly** speaking, you save .text segment in FLASH (adjusted to
> > flash block erase size), you save not ELF image! So, do not mess
> > with binaries. Also `load' command does not carry whole ELF image
> > into RAM, but .text segment with a few other segments.
> The thing is:
> I will need to work with files (new firmware should arrive to sdcard
> on the board through ftp in a main app). I want redboot to pick a new
               ^^^^^^^^^^^
> image up from sdcard at reset.

If your board has Ethernet, then you can build RedBoot with networking
support and use TFTP or HTTP protocols to load firmware blobs from the
NET. Why not? Or you talk about "main app" on a host side?

> Extracting sections from received ELF file and transferring them to
> redboot is more of a manual work.
> So, I think I am kind of stuck with ELF files.
> 
> So I am thinking:
> 
> * Should I load compressed ELF file (gzip) with -d switch?
> 
> * Should I load SREC file (they are usually smaller than ELF)?

If you talk about eCos executables (to load) then regardless of the
source format you have to keep in a place only sections with LOAD
attribute. Look

  stat -c %s install/tests/kernel/current/tests/tm_basic
  608261

Thus, ELF size is 608K. Let's get a binary to load (in RAM for my case)

  arm-eabi-objcopy -O binary install/tests/kernel/current/tests/tm_basic{,.bin}
  stat -c %s install/tests/kernel/current/tests/tm_basic.bin
  47248

Binary image size is 47K or exactly 47248 bytes. What that 47K is? Let's
print all section's headers of ELF

  arm-eabi-objdump -h install/tests/kernel/current/tests/tm_basic

You will see all sections its sizes, locations and even more. But we
need to load only the sections which have attribute *LOAD* (not bad
name for 'load' command). Filter those sections

  arm-eabi-objdump -h install/tests/kernel/current/tests/tm_basic | grep LOAD -B1
    8 .rom_vectors  00000040  81008000  81008000  00008000  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    9 .text         0000a704  81008040  81008040  00008040  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   10 .rodata       00000e60  81012744  81012744  00012744  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, DATA
   11 .data         000002ec  810135a4  810135a4  000135a4  2**2
                    CONTENTS, ALLOC, LOAD, DATA

Let's calculate sum of all sizes

  echo "ibase=16; 40+A704+E60+2EC" | bc
  47248

We got exactly 47248 bytes. Again, regardless source file format (srec,
elf, bin) you have to save on a media *at least* those *LOAD* bytes and
you (or loader) have to know all LMA (Load Memory Address) addresses to
relocate the sections (if that is needed) in the right places.

> * Should I save executable sections and store them in a file. Transfer
> that file to sdcard for redboot to pick it up at reset.  (nor sure how
> to do it actually)
 
What do you want to save? SD card space? Internal FLASH space? Loading
time?

> * Can I actually load a .bin (image in binary format)?

Yes, you can. You would even manage the loading of compressed binary images
(.bin.gz).

HTH

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

Thanks Sergei,

>>> ELF files are quite large, what is the preferred format for an image
>>> to be passed to redboot?  what "load" and "fis create" command look
>>> like?
>>> **Roughly** speaking, you save .text segment in FLASH (adjusted to
>>> flash block erase size), you save not ELF image! So, do not mess
>>> with binaries. Also `load' command does not carry whole ELF image
>>> into RAM, but .text segment with a few other segments.
>> The thing is:
>> I will need to work with files (new firmware should arrive to sdcard
>> on the board through ftp in a main app). I want redboot to pick a new
>                 ^^^^^^^^^^^
>> image up from sdcard at reset.
> If your board has Ethernet, then you can build RedBoot with networking
> support and use TFTP or HTTP protocols to load firmware blobs from the
> NET. Why not? Or you talk about "main app" on a host side?

No there is no Ethernet chip. I have GPRS modem on the board and I use 
LWIP 1.3.2 stack from eCos. FTP is to be custom made using RAW sockets.

>> Extracting sections from received ELF file and transferring them to
>> redboot is more of a manual work.
>> So, I think I am kind of stuck with ELF files.
>>
>> So I am thinking:
>>
>> * Should I load compressed ELF file (gzip) with -d switch?
>>
>> * Should I load SREC file (they are usually smaller than ELF)?
> If you talk about eCos executables (to load) then regardless of the
> source format you have to keep in a place only sections with LOAD
> attribute. Look
>
>    stat -c %s install/tests/kernel/current/tests/tm_basic
>    608261
>
> Thus, ELF size is 608K. Let's get a binary to load (in RAM for my case)
>
>    arm-eabi-objcopy -O binary install/tests/kernel/current/tests/tm_basic{,.bin}
>    stat -c %s install/tests/kernel/current/tests/tm_basic.bin
>    47248
>
> Binary image size is 47K or exactly 47248 bytes. What that 47K is? Let's
> print all section's headers of ELF
>
>    arm-eabi-objdump -h install/tests/kernel/current/tests/tm_basic
>
> You will see all sections its sizes, locations and even more. But we
> need to load only the sections which have attribute *LOAD* (not bad
> name for 'load' command). Filter those sections
>
>    arm-eabi-objdump -h install/tests/kernel/current/tests/tm_basic | grep LOAD -B1
>      8 .rom_vectors  00000040  81008000  81008000  00008000  2**2
>                      CONTENTS, ALLOC, LOAD, READONLY, CODE
>      9 .text         0000a704  81008040  81008040  00008040  2**2
>                      CONTENTS, ALLOC, LOAD, READONLY, CODE
>     10 .rodata       00000e60  81012744  81012744  00012744  2**2
>                      CONTENTS, ALLOC, LOAD, READONLY, DATA
>     11 .data         000002ec  810135a4  810135a4  000135a4  2**2
>                      CONTENTS, ALLOC, LOAD, DATA
>
> Let's calculate sum of all sizes
>
>    echo "ibase=16; 40+A704+E60+2EC" | bc
>    47248
>
> We got exactly 47248 bytes. Again, regardless source file format (srec,
> elf, bin) you have to save on a media *at least* those *LOAD* bytes and
> you (or loader) have to know all LMA (Load Memory Address) addresses to
> relocate the sections (if that is needed) in the right places.
>
>> * Should I save executable sections and store them in a file. Transfer
>> that file to sdcard for redboot to pick it up at reset.  (nor sure how
>> to do it actually)
>   
> What do you want to save? SD card space? Internal FLASH space? Loading
> time?
>

I meant saving *LOAD* bytes in a file and sending that file to the board 
via ftp.
Not sure how to specify that info, i.e. what to get from a file (section 
addresses and sizes) and where to relocate them in memory (LMA).
ELF contains this info.

>> * Can I actually load a .bin (image in binary format)?
> Yes, you can. You would even manage the loading of compressed binary images
> (.bin.gz).
Oh, that sounds promising.

But I am unable to load .bin with "load -m x" and create fis with "fis 
create <name>"

RedBoot> load -m x
CUnrecognized image type: 0x64200000
xyzModem - CRC mode, 32(SOH)/0(STX)/0(CAN) packets, 4 retries
RedBoot> fis create appbin
*** invalid 'fis' command: required parameter missing
...

What is the correct usage of "load" and "fis create" when you deal with 
.bin file?
(Perhaps I need to specify switches, not sure which ones. Sorry for 
being dumb )) )

info about my app.bin:

Entry point address:               0x64008111 (from elf file)

mlt_*.ldi file used:
SECTIONS
{
     SECTIONS_BEGIN
     SECTION_sram (sram, hal_virtual_vector_table_end, LMA_EQ_VMA)
     SECTION_rom_vectors (ram, 0x64008000, LMA_EQ_VMA)
     SECTION_RELOCS (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_text (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fini (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_rodata (ram, ALIGN(0x8), LMA_EQ_VMA)
     SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fixup (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_gcc_except_table (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_eh_frame (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_got (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
     SECTIONS_END
}

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov]

On Fri, 10 Oct 2014, Oleg Uzenkov wrote:

> No there is no Ethernet chip. I have GPRS modem on the board and I use
> LWIP 1.3.2 stack from eCos. FTP is to be custom made using RAW
> sockets.

<snip>

> I meant saving *LOAD* bytes in a file and sending that file to the
> board via ftp.  Not sure how to specify that info, i.e. what to get
> from a file (section addresses and sizes) and where to relocate them
> in memory (LMA).  ELF contains this info.

Well, you want to minimize size of image to upload. Use any compressed
image to upload it with X/YMODEM (must have zlib package in RedBoot)

Continue with tm_basic example ([RAM] startup)

  size    name
  ----    ----
  621463  install/tests/kernel/current/tests/tm_basic
  47248   install/tests/kernel/current/tests/tm_basic.bin
  80936   install/tests/kernel/current/tests/tm_basic.img
  141868  install/tests/kernel/current/tests/tm_basic.srec

NOTE: `tm_basic.img' is stripped ELF (no debug info) you can get such an
       image as,  arm-eabi-strip -s <name> -o <name>.img

Compressed (gzip -9) images

  size    name
  ----    ----
  23998   install/tests/kernel/current/tests/tm_basic.bin.gz
  222086  install/tests/kernel/current/tests/tm_basic.gz
  24471   install/tests/kernel/current/tests/tm_basic.img.gz
  42290   install/tests/kernel/current/tests/tm_basic.srec.gz

> But I am unable to load .bin with "load -m x" and create fis with "fis
> create <name>"

As you can see, *.img.gz has almost the same size as *.bin.gz. So, to
upload *.img.gz files you need to add the only -d(ecompress) switch.

  load -m x -d
  fis create <name>

For binaries you have to know the first LMA address (rom_vectors
address) to specify that address on a command line.

For binary image

  load -m x -r -b <LMA>
  fis create -b <LMA> <name>

For gzipped binary image

  load -d -m x -r -b <LMA>
  fis create -b <LMA> ?-l <LENGTH>? <name>

But I suggest you to compress stripped ELFs and use simple sequence

  load -d -m x
  fis create <name>
  ...
  fis load <name>
  go

The above is about how you would upload (load cmd), save (fis create),
load (fis load) and run (go cmd) when image is built for RAM startup
and of course, your target must have enough RAM to spin *LOAD* bytes
(i.e. do load, load-decompress, or fis-load, fis-load-decompress).

For FLASH XIP images you have to use another sequences of RedBoot
commands, perhaps, load -> fis write -> go <LMA>.

You can find all needed info on RedBoot commands here

  http://ecos.sourceware.org/docs-latest/redboot/redboot-guide.html

REMEMBER: using ELFs means using less of switches in RedBoot commands
and using blobs means that you have to use more "smart" switches and
sequences the commands and you have to know where LOAD bytes are and
what LMA is.

Yet another story if you have file system support in RedBoot. Sorry, I
can't reproduce all scenarios in short answer and I don't want annoy the
list by retelling the RedBoot guide. Please, Read The Fine Manual :-)

Regarding your environment and requirements. Sure, all is possible, but
I would  prefer to get more RAM on the board that lets use standard ways
to manage all issues. However, they do design hardware and we must solve
the puzzles :-)

Happy Hacking!

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

Re: [ECOS] redboot on STM32f4-discovery board

[Oleg Uzenkov]

Hi,

I have got redboot working on my board (with no external ram).

When I set (CYGBLD_REDBOOT_LOAD_INTO_FLASH == 1) I get such response:

RAM: 0x20000000-0x2001f000 [0x200039c8-0x1fff3000 available]
0x10000000-0x10010000 [0x10000000-0x10010000 available]
FLASH: 0x08000000-0x0807ffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 3 x 
0x20000 blocks
RedBoot>

*Note* invalid RAM range ([0x200039c8-0x1fff3000 available]).


When I set (CYGBLD_REDBOOT_LOAD_INTO_FLASH == 0) I get:

RAM: 0x20000000-0x2001f000 [0x20003998-0x20013000 available]
0x10000000-0x10010000 [0x10000000-0x10010000 available]
FLASH: 0x08000000-0x0807ffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 3 x 
0x20000 blocks
RedBoot>

*RAM range is valid*
It looks like CYGBLD_REDBOOT_LOAD_INTO_FLASH functionality occupies 
0x20013000−0x1fff3000=0x20000 (this is actually the size of a flash 
block (at the end on stm32f407, 128K)).

This is the Flash geometry I am using:
#define STM32_FLASH_SIZE (512*1024)
#define STM32_FLASH_BLOCK_INFO { { { 16*1024, 4 } , { 64*1024, 1 }, { 
128*1024, 3} } }
#define STM32_FLASH_NUM_BLOCK_INFOS 3

It looks like a lot of RAM is used by CYGBLD_REDBOOT_LOAD_INTO_FLASH 
functionality. Or does it depend on flash block size it is mapped to?

Can I shift it to occupy a smaller block of flash (for example 4th from 
the end - 64K)?


BTW, what occupies the memory from 0x20013000 to 0x2001f000? I do not 
have CYGOPT_REDBOOT_FIS enabled. It is usually FIS that occupies the end 
of flash address map, but as I said it is disabled.


With best wishes,
Oleg






> On Thu, 9 Oct 2014, Oleg Uzenkov wrote:
>
>> But, without Flash Image System I do not see how to use redboot to
>> load and store and run images.
> Even for builds (CYGOPT_REDBOOT_FIS == 0) you can manage FLASH using
> absolute FLASH addresses and FIS sub-commands: erase and write.
>
> When you make RedBoot work smoothly on your target, then you can try to
> load images directly to FLASH if you enable
>
>    cdl_option CYGBLD_REDBOOT_LOAD_INTO_FLASH {
>        user_value 1
>    };
>
> eCos is designed with XIP (eXecute In Place) in mind and you can use
> RedBoot 'go' command to execute ROM image from specified place of FLASH.
>
> For simple applications it would be enough just to shift *rom* ORIGIN
> address and *rom_vectors* address in `target.ld' file and re-link ROM
> application, then with the option above it is possible to load and run
> such ROM image as
>
>    load -m <protocol>
>    go
>
> I call that it worked on my target (load-into-flash-and-go). However,
> you need to inspect and may be fix HAL startup files for such "FLASH"
> builds.
>
> 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

Re: [ECOS] redboot on STM32f4-discovery board

[Sergei Gavrikov]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2421 bytes --]

On Mon, 13 Oct 2014, Oleg Uzenkov wrote:

> Hi,
>
> I have got redboot working on my board (with no external ram).
>
> When I set (CYGBLD_REDBOOT_LOAD_INTO_FLASH == 1) I get such response:
>
> RAM: 0x20000000-0x2001f000 [0x200039c8-0x1fff3000 available]
> 0x10000000-0x10010000 [0x10000000-0x10010000 available]
> FLASH: 0x08000000-0x0807ffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 3 x 0x20000 blocks
> RedBoot>
>
> *Note* invalid RAM range ([0x200039c8-0x1fff3000 available]).
>
>
> When I set (CYGBLD_REDBOOT_LOAD_INTO_FLASH == 0) I get:
>
> RAM: 0x20000000-0x2001f000 [0x20003998-0x20013000 available]
> 0x10000000-0x10010000 [0x10000000-0x10010000 available]
> FLASH: 0x08000000-0x0807ffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 3 x 0x20000 blocks
> RedBoot>
>
> *RAM range is valid*
> It looks like CYGBLD_REDBOOT_LOAD_INTO_FLASH functionality occupies
> 0x20013000−0x1fff3000=0x20000 (this is actually the size of a flash
> block (at the end on stm32f407, 128K)).

Exactly. Look at lines 165-176

  http://hg-pub.ecoscentric.com/ecos/file/tip/packages/redboot/current/src/flash_load.c

That 128K buffer is the largest flash block size what does shift
workspace_end and you get wrong RAM stat.

> This is the Flash geometry I am using:
> #define STM32_FLASH_SIZE (512*1024)
> #define STM32_FLASH_BLOCK_INFO { { { 16*1024, 4 } , { 64*1024, 1 }, { 128*1024, 3} } }
> #define STM32_FLASH_NUM_BLOCK_INFOS 3
>
> It looks like a lot of RAM is used by CYGBLD_REDBOOT_LOAD_INTO_FLASH
> functionality. Or does it depend on flash block size it is mapped to?

No code overhead there, it does depend on flash block size.  So, using
of CYGBLD_REDBOOT_LOAD_INTO_FLASH on your target make things worse.

> Can I shift it to occupy a smaller block of flash (for example 4th
> from the end - 64K)?

You can (would), if you get rid the rest of FLASH, 128K x 3.

> BTW, what occupies the memory from 0x20013000 to 0x2001f000? I do not
> have CYGOPT_REDBOOT_FIS enabled. It is usually FIS that occupies the
> end of flash address map, but as I said it is disabled.

That may be fis+zlib buffer, CYGNUM_REDBOOT_FIS_ZLIB_COMMON_BUFFER_SIZE
(0xC000 by default), may be I wrong.

It is clear that RedBoot workspace region on your target is too small to
fit ALL your needs (compressing and direct flash writing).

Well, it is possible to utilize .ccm segment for "large" buffers, but
that cannot be done through CDL options.


Sergei

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

Hi Everyone,

>
> For binaries you have to know the first LMA address (rom_vectors
> address) to specify that address on a command line.
>
> For binary image
>
>    load -m x -r -b <LMA>
>    fis create -b <LMA> <name>
Please, let me know what do you think of this:

1) I have built app.elf and app.bin for *RAM* startup 
(SECTION_rom_vectors: LMA == 0x64008000 )
(memory layout is mlt_cortexm_stm32x0g_eval_ram.ldi)

2) I can successfuly run app.elf under redboot (i.e. >load -m x; >go)

3) When I load app.bin like this:
 >load -m x -r -b 0x64008000
 >go 0x64008000
or
 >go

I get rubbish ($T080f:00800064;0d:e8cf1b64;)
(i also tried to create fis and load and run image from fis, same 
result, i.e. >fis create -b 0x64008000 app; >fis load app; >go)

any ideas where I am wrong?

Did anyone manage to execute .bin file from Redboot?

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov]

On Wed, 15 Oct 2014, Oleg Uzenkov wrote:

> > For binaries you have to know the first LMA address (rom_vectors
> > address) to specify that address on a command line.
> >
> > For binary image
> >
> >    load -m x -r -b <LMA>
> >    fis create -b <LMA> <name>
> Please, let me know what do you think of this:
>
> 1) I have built app.elf and app.bin for *RAM* startup
> (SECTION_rom_vectors: LMA == 0x64008000 ) (memory layout is
> mlt_cortexm_stm32x0g_eval_ram.ldi)
>
> 2) I can successfuly run app.elf under redboot (i.e. >load -m x; >go)
>
> 3) When I load app.bin like this:
> >load -m x -r -b 0x64008000
> >go 0x64008000
> or
> >go

RedBoot 'load' command does stat info about 'Entry point'. For example
on my ARM target

  RedBoot> load -m y
  Entry point: 0x81008040, address range: 0x81008000-0x81013890
  xyzModem - CRC mode, 627(SOH)/0(STX)/0(CAN) packets, 2 retries
  RedBoot>

Load address 0x81008000 and entry point (LMA of .text) is 0x81008040.

If I load a binary, I got something likes this

  RedBoot> load -m y -r -b 0x81008000
  CRaw file loaded 0x81008000-0x8101388f, assumed entry at 0x81008000
  xyzModem - CRC mode, 372(SOH)/0(STX)/0(CAN) packets, 3 retries
  RedBoot>

RedBoot has no clue where start from (it can guess only, 'assumed
entry')

From your old message

  http://ecos.sourceware.org/ml/ecos-discuss/2014-10/msg00007.html

I see that after loading PC register will be set to 0x64008110, so try

  RedBoot> go 0x64008110

> I get rubbish ($T080f:00800064;0d:e8cf1b64;)

Connect GDB to get it.

> (i also tried to create fis and load and run image from fis, same
> result, i.e.
> >fis create -b 0x64008000 app; >fis load app; >go)
>
> any ideas where I am wrong?

See/try above.

>
> Did anyone manage to execute .bin file from Redboot?

It should work.

HTH

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

Thanks Sergei!

I can confirm that loading and running .bin files works now ))

For someone with the same problem here is a piece of information:

1. From objdump command below  we see that .rom_vectors section address 
is 0x64008000 and .text section starts at 0x64008110.

arm-none-eabi-objdump -h app.elf | grep LOAD -B1

   0 .rom_vectors  00000008  64008000  64008000  00000098  2**0
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .ARM.extab    0000003c  64008008  64008008  000000a0  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   2 .ARM.exidx    000000c8  64008048  64008048  000000e0  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   3 .text         0000595c  64008110  64008110  000001a8  2**3
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   4 .rodata       00000204  6400da70  6400da70  00005b08  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
--
   6 .data         000002a8  6400dc80  6400dc80  00005d10  2**3
                   CONTENTS, ALLOC, LOAD, DATA

2. Check Entry point address with readelf command. In my case Entry 
point address:  0x64008111

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:               0x64008111
   Start of program headers:          52 (bytes into file)
   Start of section headers:          24700 (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

3. Now load .bin

RedBoot> load -m x -r -b 0x64008000
CRaw file loaded 0x64008000-0x6400df27, assumed entry at 0x64008000
xyzModem - CRC mode, 191(SOH)/0(STX)/0(CAN) packets, 5 retries
RedBoot>

4. Now run binary with:
RedBoot> go 0x64008111


Oleg



> On Wed, 15 Oct 2014, Oleg Uzenkov wrote:
>
>>> For binaries you have to know the first LMA address (rom_vectors
>>> address) to specify that address on a command line.
>>>
>>> For binary image
>>>
>>>     load -m x -r -b <LMA>
>>>     fis create -b <LMA> <name>
>> Please, let me know what do you think of this:
>>
>> 1) I have built app.elf and app.bin for *RAM* startup
>> (SECTION_rom_vectors: LMA == 0x64008000 ) (memory layout is
>> mlt_cortexm_stm32x0g_eval_ram.ldi)
>>
>> 2) I can successfuly run app.elf under redboot (i.e. >load -m x; >go)
>>
>> 3) When I load app.bin like this:
>>> load -m x -r -b 0x64008000
>>> go 0x64008000
>> or
>>> go
> RedBoot 'load' command does stat info about 'Entry point'. For example
> on my ARM target
>
>    RedBoot> load -m y
>    Entry point: 0x81008040, address range: 0x81008000-0x81013890
>    xyzModem - CRC mode, 627(SOH)/0(STX)/0(CAN) packets, 2 retries
>    RedBoot>
>
> Load address 0x81008000 and entry point (LMA of .text) is 0x81008040.
>
> If I load a binary, I got something likes this
>
>    RedBoot> load -m y -r -b 0x81008000
>    CRaw file loaded 0x81008000-0x8101388f, assumed entry at 0x81008000
>    xyzModem - CRC mode, 372(SOH)/0(STX)/0(CAN) packets, 3 retries
>    RedBoot>
>
> RedBoot has no clue where start from (it can guess only, 'assumed
> entry')
>
>  From your old message
>
>    http://ecos.sourceware.org/ml/ecos-discuss/2014-10/msg00007.html
>
> I see that after loading PC register will be set to 0x64008110, so try
>
>    RedBoot> go 0x64008110
>
>> I get rubbish ($T080f:00800064;0d:e8cf1b64;)
> Connect GDB to get it.
>
>> (i also tried to create fis and load and run image from fis, same
>> result, i.e.
>>> fis create -b 0x64008000 app; >fis load app; >go)
>> any ideas where I am wrong?
> See/try above.
>
>> Did anyone manage to execute .bin file from Redboot?
> It should work.
>
> HTH
>
> 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

Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov]

On Thu, 16 Oct 2014, Oleg Uzenkov wrote:

> Thanks Sergei!
>
> I can confirm that loading and running .bin files works now ))
>
> For someone with the same problem here is a piece of information:
>
> 1. From objdump command below  we see that .rom_vectors section
> address is 0x64008000 and .text section starts at 0x64008110.

...

To be more precise, .text begins itself from 'reset_vector' address (it
is public label). See arch's target.ld and vectors.S sources.

> 2. Check Entry point address with readelf command. In my case Entry
> point address:  0x64008111

...

It is strange value as 0x64008111 is odd address, but 'reset_vector'
address for your arch should be aligned on 2-bytes boundary. I believe
that entry address is 0x64008110 or some even address. Try in GDB

  (gdb) load
  (gdb) print $pc
  (gdb) print reset_vector

or disassembly

  % arm-eabi-objdump -d app.elf | more

I think you see 0x64008110.

> 3. Now load .bin
>
> RedBoot> load -m x -r -b 0x64008000
> CRaw file loaded 0x64008000-0x6400df27, assumed entry at 0x64008000
> xyzModem - CRC mode, 191(SOH)/0(STX)/0(CAN) packets, 5 retries
> RedBoot>
>
> 4. Now run binary with:
> RedBoot> go 0x64008111

Just wondering, 'go 0x640008110' does not work?

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

Re: [ECOS] redboot on STM3240G-EVAL board

[Oleg Uzenkov]

> On Thu, 16 Oct 2014, Oleg Uzenkov wrote:
>
>> Thanks Sergei!
>>
>> I can confirm that loading and running .bin files works now ))
>>
>> For someone with the same problem here is a piece of information:
>>
>> 1. From objdump command below  we see that .rom_vectors section
>> address is 0x64008000 and .text section starts at 0x64008110.
> ...
>
> To be more precise, .text begins itself from 'reset_vector' address (it
> is public label). See arch's target.ld and vectors.S sources.
>
>> 2. Check Entry point address with readelf command. In my case Entry
>> point address:  0x64008111
> ...
>
> It is strange value as 0x64008111 is odd address, but 'reset_vector'
> address for your arch should be aligned on 2-bytes boundary. I believe
> that entry address is 0x64008110 or some even address. Try in GDB
>
>    (gdb) load
>    (gdb) print $pc
>    (gdb) print reset_vector
>
> or disassembly
>
>    % arm-eabi-objdump -d app.elf | more
>
> I think you see 0x64008110.
Yes, I you are right, this is what I see:

arm-none-eabi-gdb -b 115200 app.elf
(gdb) target remote /dev/ttyUSB0
(gdb) load
(gdb) print $pc
$1 = (void (*)()) 0x64008110

However, when I do:
 >go 0x640008110 in RedBoot it does not work!

it only works if I do:
 >go 0x640008111

I agree it is strange. It should be even address.

Do you know if it is possible to use gdb with binaries?
Only I was unable to do it.
arm-none-eabi-gdb -b 38400 ./app.bin
(gdb) target remote /dev/ttyUSB0
(gdb) load app.bin
"app.bin" is not an object file: File format not recognized
Perhaps, it can only works with ELF that contains symbols, where as .bin 
file is stripped of them.

Oleg

>> 3. Now load .bin
>>
>> RedBoot> load -m x -r -b 0x64008000
>> CRaw file loaded 0x64008000-0x6400df27, assumed entry at 0x64008000
>> xyzModem - CRC mode, 191(SOH)/0(STX)/0(CAN) packets, 5 retries
>> RedBoot>
>>
>> 4. Now run binary with:
>> RedBoot> go 0x64008111
> Just wondering, 'go 0x640008110' does not work?
>
> 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

[ECOS] Re: redboot on STM32f4-discovery board

[Oleg Uzenkov]

Hi John,

I managed to get redboot running on the board (without external ram)
redboot has been built with (CYGOPT_REDBOOT_FIS == 0) and it is stable.

I even can do:
RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Console baud rate: 115200
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0x08040000-0x08040fff: .
... Program from 0x20012000-0x20013000 to 0x08040000: .
RedBoot>


There is something strange in what I have noticed:

Output with (CYGBLD_REDBOOT_LOAD_INTO_FLASH == 0):

RAM: 0x20000000-0x2001f000 [0x20003a58-0x20010000 available]
       0x10000000-0x10010000 [0x10000000-0x10010000 available]
FLASH: 0x08000000-0x0807ffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 3 x
0x20000 blocks
RedBoot>

(RedBoot is using 0x3a58 bytes of internal RAM.)

Output with (CYGBLD_REDBOOT_LOAD_INTO_FLASH == 1) (nothing else was
modified):

RAM: 0x20000000-0x2001f000 [0x20003a88-0x1fff0000 available]
       0x10000000-0x10010000 [0x10000000-0x10010000 available]
FLASH: 0x08000000-0x0807ffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 3 x
0x20000 blocks
RedBoot>

Notice [0x20003a88-0x1fff0000 available]: range is invalid. Any ideas why?



How can I load a small .elf file (built for RAM startup) now and store
it in internal flash and execute? :-)

this is what happens when i do:

RedBoot> load -m x
C*** Abort! Attempt to load ELF data to address: 0x20000288 which is not
valid
xyzModem - CRC mode, 2(SOH)/0(STX)/0(CAN) packets, 3 retries
RedBoot>

address 0x20000288 is not valid probably because we have
[0x20003a58-0x20010000 available]
and 0x20000288 is occupied by redboot. What do I do?

Oleg



> Hi Oleg
>
> On 09/10/14 16:48, Oleg Uzenkov wrote:
>
>> I have tried to run redboot on a custom board (very similar to
>> STM32f4-discovery board, so let's say that we have discovery in question).
> [ snip ]
>
>> I just would like to get redboot working on a board without external RAM.
>>
>> These are my findings so far:
>>
>> 1. I built redboot for ROM startup (applied relevant adjustings from
>> stm3240g_eval's  redboot_rom.ecm)
>>
>> 2. flashed the board with redboot at 0x08000000
>>
>> 3.
>> when CYGOPT_REDBOOT_FIS == 0 redboot loads, but is very unstable, can
>> stop working any time... But, without Flash Image System I do not see
>> how to use redboot to load and store and run images.
>>
>> when CYGOPT_REDBOOT_FIS == 1  redboot hangs.  It happens when
>> do_flash_init() runs (problem in memcpy , probably illigal memory access)
>>
>> A question, can actually redboot work without external ram?
>>
>> If yes, how to fit it properly? (the board has stm32f407VE with 128+64
>> KB of internal ram, 512KB internal flash)
> Consider the output of RedBoot on STM3240G-EVAL (from your earlier message):
>
>> RedBoot(tm) bootstrap and debug environment [ROM]
>> ...
>> Platform: ST STM3240G-EVAL (Cortex-M4)
>> RAM: 0x64000000-0x64200000 [0x64005d30-0x641dd000 available]
>>       0x20000000-0x2001f000 [0x20000000-0x2001f000 available]
>>       0x10000000-0x10010000 [0x10000000-0x10010000 available]
>> FLASH: 0x08000000-0x080fffff, 4 x 0x4000 blocks, 1 x 0x10000 blocks, 7 x 0x20000 blocks
>> RedBoot>
> This shows that RedBoot is using 0x5d30 bytes of external RAM with FIS
> enabled. If you have ported RedBoot to your custom board correctly, I
> would expect it to report internal RAM usage similar, but not identical,
> to the following:
>
>> RAM: 0x20000000-0x2001f000 [0x20005d30-0x2001f000 available]
> Is that what you are observing?
>
> So RedBoot should fit it available RAM quite easily.
>
> I would concentrate on tracking down the reliability issue when RedBoot
> is configured without the FIS first. Once you have a stable RedBoot
> without the FIS, you can then try enabling the FIS.
>
> I hope this helps....
>
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
>




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