[Bug 1001623] [RFC] eCos FLASH startup from RedBoot

[bugzilla-daemon@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.