public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Oleg Uzenkov <o.uzenkov@unicore.co.ua>
To: eCos Discussion <ecos-discuss@sourceware.org>
Subject: [ECOS] redboot on STM32f4-discovery board
Date: Thu, 09 Oct 2014 15:48:00 -0000	[thread overview]
Message-ID: <5436AE5C.6060401@unicore.co.ua> (raw)
In-Reply-To: <543003B9.20300@siva.com.mk>

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

  parent reply	other threads:[~2014-10-09 15:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02  8:47 Oleg Uzenkov
2014-10-03 11:40 ` [ECOS] " John Dallaway
2014-10-04 14:27   ` "Ilija Kocho [Илија Кочо]"
2014-10-05  8:32     ` Oleg Uzenkov
2014-10-05  9:56       ` "Ilija Kocho [Илија Кочо]"
2014-10-09 15:48     ` Oleg Uzenkov [this message]
2014-10-09 18:44       ` John Dallaway
2014-10-09 21:12       ` [ECOS] " Sergei Gavrikov
2014-10-13 11:59         ` Oleg Uzenkov
2014-10-13 15:10           ` Sergei Gavrikov
2014-10-09 11:33   ` [ECOS] redboot on STM3240G-EVAL board Oleg Uzenkov
2014-10-09 12:36     ` Edgar Grimberg
2014-10-09 13:42       ` Oleg Uzenkov
2014-10-09 13:45     ` Sergei Gavrikov
2014-10-09 14:08       ` Oleg Uzenkov
2014-10-09 14:35         ` Sergei Gavrikov
2014-10-10  5:52           ` Oleg Uzenkov
2014-10-10  7:55             ` Sergei Gavrikov
2014-10-10  8:52               ` Oleg Uzenkov
2014-10-10 15:58                 ` Sergei Gavrikov
2014-10-15 11:50                   ` Oleg Uzenkov
2014-10-15 14:45                     ` Sergei Gavrikov
2014-10-16  8:08                       ` Oleg Uzenkov
2014-10-16 15:01                         ` Sergei Gavrikov
2014-10-17  9:15                           ` Oleg Uzenkov

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=5436AE5C.6060401@unicore.co.ua \
    --to=o.uzenkov@unicore.co.ua \
    --cc=ecos-discuss@sourceware.org \
    /path/to/YOUR_REPLY

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

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