[ECOS] redboot on STM32f4-discovery board

Sergei Gavrikov sergei.gavrikov@gmail.com
Mon Oct 13 15:10:00 GMT 2014


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
-------------- next part --------------
-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


More information about the Ecos-discuss mailing list