public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Gavrikov <sergei.gavrikov@gmail.com>
To: Oleg Uzenkov <o.uzenkov@unicore.co.ua>
Cc: eCos Discussion <ecos-discuss@sourceware.org>
Subject: Re: [ECOS] redboot on STM32f4-discovery board
Date: Mon, 13 Oct 2014 15:10:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1410131629030.8298@sg-laptop> (raw)
In-Reply-To: <543BBEAB.8040000@unicore.co.ua>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2421 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2014-10-13 15:10 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     ` [ECOS] " Oleg Uzenkov
2014-10-09 18:44       ` [ECOS] " John Dallaway
2014-10-09 21:12       ` [ECOS] " Sergei Gavrikov
2014-10-13 11:59         ` Oleg Uzenkov
2014-10-13 15:10           ` Sergei Gavrikov [this message]
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=alpine.DEB.2.00.1410131629030.8298@sg-laptop \
    --to=sergei.gavrikov@gmail.com \
    --cc=ecos-discuss@sourceware.org \
    --cc=o.uzenkov@unicore.co.ua \
    /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).