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

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

           Summary: [RFC] eCos FLASH startup from RedBoot
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ilijak@siva.com.mk
                CC: ecos-patches@ecos.sourceware.org
        Depends on: 1001561
             Class: Advice Request


Created an attachment (id=1825)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1825)
Kinetis Flash startup from RedBoot

This Bug was inspired by
http://sourceware.org/ml/ecos-discuss/2012-06/msg00011.html

The attached patch provides what I have called FLASH startup by combining ROM
and RAM startups. The image can be flashed (needs Bug #1001561) and run by
means of Redboot.

RFC:
   1. Am I reinventing hot watter?
   2. The CDL defines CYG_HAL_STARTUP_ROM and CYG_HAL_STARTUP_RAM. Is there a
caveat?

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.

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

Nicolas Aujoux <nau@csm-instruments.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nau@csm-instruments.com

--- Comment #1 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-17 13:57:43 BST ---
Hello Ilija,

We also worked on it and add a new startup type too. However, we also had to
add the new startup into hal_misc.c and twr_k60n512_misc.c files for it to
work.

With this, we can load an eCos application with telnet and launch it. I could
post a patch if you want.

Nicolas.

PS : I sent you a private email, did you receive it ?

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

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-17 19:36:52 BST ---
Hello Nicolas

(In reply to comment #1)
> Hello Ilija,
> 
> We also worked on it and add a new startup type too. However, we also had to
> add the new startup into hal_misc.c and twr_k60n512_misc.c files for it to
> work.

Changes to platform files usually are not a big issue, but every touch of
architecture files may impact other variants/platforms and would be good if we
can avoid. As a consequence it may require overview of more people which can
take more time.
I wanted to try it with least impact on architecture level. It seems that by
defining/combining CYG_HAL_STARTUP_ROM and CYG_HAL_STARTUP_RAM we get what we
need without touching architecture files. I tried it worked but I had little
time for testing because I went on vacation. We should check for possible
caveats caused by defining CYG_HAL_STARTUP_ROM and CYG_HAL_STARTUP_RAM, both
startup types in their own right.

> 
> With this, we can load an eCos application with telnet and launch it. I could
> post a patch if you want.

It would be good if you post, thanks.

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.

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

--- Comment #3 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-18 15:44:22 BST ---
Created an attachment (id=1833)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1833)
RomApp startup (flash from redboot)

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

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

--- Comment #4 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-18 15:48:26 BST ---
(In reply to comment #3)
> Created an attachment (id=1833)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1833) [details]
> RomApp startup (flash from redboot)

Hi Ilija,

Here is what we have done with Pierre-Jean. Sorry in advance if the patch is
not very clean ...

Our startup type is called romapp. We (well probably not me) will check yours
just after the vacation.

Nicolas

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

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #5 from Jonathan Larmour <jifl@ecoscentric.com> 2012-07-19 02:52:18 BST ---
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. 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.

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

Jifl

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

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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-07 15:30:59 BST ---
(In reply to comment #6)

- systems and could be a real advantage for _RAM_constrained_/_FLASH_reach_
+ systems and could be a real advantage for _RAM_constrained_/_FLASH_rich_

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.

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

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623

Bug 1001623 depends on bug 1001561, which changed state.

Bug 1001561 Summary: Internal flash driver for Freescale TWR-K60N512 board
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001561

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |CURRENTRELEASE

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