From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11398 invoked by alias); 4 Oct 2014 14:27:15 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 11388 invoked by uid 89); 4 Oct 2014 14:27:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: gateway04.websitewelcome.com Received: from gateway04.websitewelcome.com (HELO gateway04.websitewelcome.com) (67.18.44.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 04 Oct 2014 14:27:13 +0000 Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 08DC1AA949134; Sat, 4 Oct 2014 09:27:11 -0500 (CDT) Received: from cm2.websitewelcome.com (unknown [192.185.178.13]) by gateway04.websitewelcome.com (Postfix) with ESMTP id F388BAA94910E for ; Sat, 4 Oct 2014 09:27:10 -0500 (CDT) Received: from montecarlo.websitewelcome.com ([192.185.12.42]) by cm2.websitewelcome.com with id z2T91o00j0uS5qw012TAFR; Sat, 04 Oct 2014 09:27:10 -0500 Received: from [77.28.168.230] (port=48032 helo=[192.168.178.21]) by montecarlo.websitewelcome.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XaQIe-0006xP-UI; Sat, 04 Oct 2014 09:27:09 -0500 Message-ID: <543003B9.20300@siva.com.mk> Date: Sat, 04 Oct 2014 14:27:00 -0000 From: =?UTF-8?B?IklsaWphIEtvY2hvIFvQmNC70LjRmNCwINCa0L7Rh9C+XSI=?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Oleg Uzenkov CC: John Dallaway , eCos Discussion References: <542D110B.9080002@unicore.co.ua> <542E8B41.8030905@dallaway.org.uk> In-Reply-To: <542E8B41.8030905@dallaway.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BWhitelist: no X-Exim-ID: 1XaQIe-0006xP-UI X-Source-Sender: ([192.168.178.21]) [77.28.168.230]:48032 X-Source-Auth: ilijak+siva.mk X-Email-Count: 3 X-Source-Cap: c2l2YW1rO2JpYmltYW47bW9udGVjYXJsby53ZWJzaXRld2VsY29tZS5jb20= X-IsSubscribed: yes Subject: Re: [ECOS] Re: redboot on STM32f4-discovery board X-SW-Source: 2014-10/txt/msg00002.txt.bz2 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