From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25530 invoked by alias); 13 Oct 2014 15:10:48 -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 25519 invoked by uid 89); 13 Oct 2014 15:10:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,MALFORMED_FREEMAIL,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-lb0-f175.google.com Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 13 Oct 2014 15:10:46 +0000 Received: by mail-lb0-f175.google.com with SMTP id u10so6507352lbd.6 for ; Mon, 13 Oct 2014 08:10:42 -0700 (PDT) X-Received: by 10.112.135.137 with SMTP id ps9mr24826066lbb.24.1413213042567; Mon, 13 Oct 2014 08:10:42 -0700 (PDT) Received: from sg-laptop (176-188.un.vitebsk.by. [86.57.176.188]) by mx.google.com with ESMTPSA id xe10sm4656091lbb.37.2014.10.13.08.10.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Oct 2014 08:10:41 -0700 (PDT) Date: Mon, 13 Oct 2014 15:10:00 -0000 From: Sergei Gavrikov To: Oleg Uzenkov cc: eCos Discussion In-Reply-To: <543BBEAB.8040000@unicore.co.ua> Message-ID: References: <542D110B.9080002@unicore.co.ua> <542E8B41.8030905@dallaway.org.uk> <543003B9.20300@siva.com.mk> <5436AE5C.6060401@unicore.co.ua> <543BBEAB.8040000@unicore.co.ua> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1988411199-1413213041=:8298" X-IsSubscribed: yes Subject: Re: [ECOS] redboot on STM32f4-discovery board X-SW-Source: 2014-10/txt/msg00020.txt.bz2 --8323329-1988411199-1413213041=:8298 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-length: 2418 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 --8323329-1988411199-1413213041=:8298 Content-Type: text/plain; charset=us-ascii Content-length: 148 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss --8323329-1988411199-1413213041=:8298--