public inbox for
 help / color / mirror / Atom feed
Subject: [Bug 1001623] [RFC] eCos FLASH startup from RedBoot
Date: Tue, 07 Aug 2012 14:14:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Please do not reply to this email. Use the web interface provided at:

Ilija Kocho <> changed:

           What    |Removed                     |Added
   Attachment #1825|0                           |1
        is obsolete|                            |
   Attachment #1833|0                           |1
        is obsolete|                            |

--- Comment #6 from Ilija Kocho <> 2012-08-07 15:14:17 BST ---
Created an attachment (id=1877)
 --> (
Kinetis Flash Startup 120807

Hi Jifl

Thanks for your comment and sorry for the delayed answer, I had (and still
have) to learn about ELF stuff.

(In reply to comment #5)
> This sort of thing could just as easily apply to most other targets, on any
> architecture. The reason this hasn't been done with those either is because you
> can't guarantee the flash base address is what you think it is - e.g. in this
> patch it's fixed at 0x20000. 

Yea, I picked 0x20000 AKA CYGBLD_REDBOOT_MIN_IMAGE_SIZE default value, but
you're right, we need some freedom. With the attached patch I'm following your
notion regarding CDL config.

What we really need is a relocating loader. It would be of benefit even for RAM
systems and could be a real advantage for _RAM_constrained_/_FLASH_reach_
devices such as many modern and announced single chip controllers.
I am interested for remote maintenance, so I am going to spend some time on
this. I would appreciate some pointers to ELF loader library with compatible

>But on a target with Flash managed by FIS, it
> could be located at arbitrary addresses. And you wouldn't be able to have two
> applications stored in flash without another startup type.
> And on many other targets with more RAM, we can use ROMRAM startup type, which
> usually offers better speed anyway.

That seem to be changing. Devices with 1 MiB or more Flash are available and
equipped with Flash accelerators and caches that offer near SRAM performance.

> Basically things start getting complicated enough that you can't easily solve
> everybody's requirements, at which point it may be better to leave it to them
> to know what they're doing, e.g. by modifying the base address in the mlt files
> themselves.
> It might be able to be argued that we could add a CDL config option for a flash
> offset, which is then added into the addresses in the ROM startup mlt files (it
> would default to 0x0).

As I mentioned before I find this idea useful, regardless of some limitations.
Once we have the relocating loader, this CDL will be a default load address.

> But I'm slightly mindful of the fact that at some point
> we would like to get back to having some form of new version of the old MLT
> host tool, and the more exotic the customisations here, the more work it would
> be to sort it all out later.

Coming to MLT is probably little-bit slower than asymptotic :-). I think that
we can build a relocating loader (as part of the eCos runtime or a utility) in
a reasonable time.


Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

  parent reply	other threads:[~2012-08-07 14:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-14 16:26 [Bug 1001623] New: " bugzilla-daemon
2012-07-17 12:58 ` [Bug 1001623] " bugzilla-daemon
2012-07-17 18:37 ` bugzilla-daemon
2012-07-18 14:44 ` bugzilla-daemon
2012-07-18 14:48 ` bugzilla-daemon
2012-07-19  1:52 ` bugzilla-daemon
2012-08-07 14:14 ` bugzilla-daemon [this message]
2012-08-07 14:31 ` bugzilla-daemon
2013-02-11 15:01 ` bugzilla-daemon

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).