This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: redboot on STM32f4-discovery board
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Oleg Uzenkov <o dot uzenkov at unicore dot co dot ua>
- Cc: eCos Discussion <ecos-discuss at sourceware dot org>
- Date: Mon, 13 Oct 2014 18:10:38 +0300 (FET)
- Subject: Re: redboot on STM32f4-discovery board
- Authentication-results: sourceware.org; auth=none
- References: <542D110B dot 9080002 at unicore dot co dot ua> <542E8B41 dot 8030905 at dallaway dot org dot uk> <543003B9 dot 20300 at siva dot com dot mk> <5436AE5C dot 6060401 at unicore dot co dot ua> <alpine dot DEB dot 2 dot 00 dot 1410092235420 dot 10121 at sg-laptop> <543BBEAB dot 8040000 at unicore dot co dot ua>
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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss