This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001623] [RFC] eCos FLASH startup from RedBoot
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Tue, 7 Aug 2012 15:14:20 +0100
- Subject: [Bug 1001623] [RFC] eCos FLASH startup from RedBoot
- Auto-submitted: auto-generated
- References: <bug-1001623-104@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1825|0 |1
is obsolete| |
Attachment #1833|0 |1
is obsolete| |
--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-07 15:14:17 BST ---
Created an attachment (id=1877)
--> (http://bugs.ecos.sourceware.org/attachment.cgi?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
license.
>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.
Ilija
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.