[Bug 1001561] New: Internal flash driver for Freescale TWR-K60N512 board

[Bug 1001561] New: Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

           Summary: Internal flash driver for Freescale TWR-K60N512 board
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: nau@csm-instruments.com
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1697)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1697)
Ecos patch for twr-k60n512 flash driver

Here is what I have done so far with my work on the freescale TWR_K60N512 flash
driver. 

I thought it would be a good idea to share it even if it is not completely
finished :
I have been successfully able to launch the "flash1" test given by ecos on some
flash blocks but not on the entire flash : I have some errors if I run the
flash test between 0x00040000 - ~0x00045000 and near 0x0000000.

When I compile redboot with Flash support, I have a strange error if I check
either "keep redboot configuration data in flash" or "redboot flash image
system support" in the redboot configuration. Otherwise, redboot give me a
working prompt.

I will keep working on it but any help or ideas for possible solutions are, of
course, very welcome.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1697|                            |assignment?
               Flag|                            |
   Attachment #1697|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #1697|0                           |1
           is patch|                            |

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-12 18:43:07 BST ---
(From update of attachment 1697)
Hi Nicolas

Thank you for your contribution, it would be nice to have Kinetis flash support
in eCos.

In order to include your code in the official eCos repository we need your
copyright assignment. Please visit http://ecos.sourceware.org/assign.html for
explanation of the reasons for copyright assignment as well as the procedure
instructions.

The copyright assignment process will take some time, but in meantime we can
prepare your code for inclusion. Apart from notes below, I would start with
code review as soon as you inform me that you have started with copyright
assignment (that means you have sent materials to FSF).

Now some general notes on your flash driver:

1. I imagine that all Kinetis parts have identical or similar Flash modules so
the driver, especially code, should be common at variant level. Platforms then
would mostly have configuration CDL.

1.a. It would help if you break the patch in several files, typically: driver,
variant, platform, ecos.db, etc). Regarding ecos.db it is sometimes better to
submit packages as plain text file rather than diff.

2. I can notice some temporary files left by your editor. Please try to keep
your code clean.

That's all for now.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1697|assignment?                 |
               Flag|                            |
   Attachment #1697|0                           |1
        is obsolete|                            |

--- Comment #2 from Nicolas Aujoux <nau@csm-instruments.com> 2012-04-19 14:11:27 BST ---
Created an attachment (id=1702)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1702)
Driver part of the flash

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #3 from Nicolas Aujoux <nau@csm-instruments.com> 2012-04-19 14:12:31 BST ---
Created an attachment (id=1703)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1703)
Hal part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #4 from Nicolas Aujoux <nau@csm-instruments.com> 2012-04-19 14:13:28 BST ---
Created an attachment (id=1704)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1704)
Database including kinetis flash component

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #5 from Nicolas Aujoux <nau@csm-instruments.com> 2012-04-19 14:34:17 BST ---
Hi Ilija

I sent the e-mail requested for the copyright assignment and I am waiting for
their answer.

I updated the attachments :

- I move the common code to the variant level.

- I separated them as you recommended.

- I deleted the temporary files (sorry about that).

Also I figured out why I wasn't able to access some part of the flash. In fact
speculation logic and cache aliasing (which are enable by default) are not
supported on some tower boards. See there for more informations :
http://forums.freescale.com/t5/Kinetis-ARM-Cortex-M4/Accessing-the-FLASH-causing-BUS-fault/m-p/78873#M509

I added an option to disable these options in the cdl file. The driver should
now work properly.

Nicolas


(In reply to comment #1)
> (From update of attachment 1697 [details])
> Hi Nicolas
> 
> Thank you for your contribution, it would be nice to have Kinetis flash support
> in eCos.
> 
> In order to include your code in the official eCos repository we need your
> copyright assignment. Please visit http://ecos.sourceware.org/assign.html for
> explanation of the reasons for copyright assignment as well as the procedure
> instructions.
> 
> The copyright assignment process will take some time, but in meantime we can
> prepare your code for inclusion. Apart from notes below, I would start with
> code review as soon as you inform me that you have started with copyright
> assignment (that means you have sent materials to FSF).
> 
> Now some general notes on your flash driver:
> 
> 1. I imagine that all Kinetis parts have identical or similar Flash modules so
> the driver, especially code, should be common at variant level. Platforms then
> would mostly have configuration CDL.
> 
> 1.a. It would help if you break the patch in several files, typically: driver,
> variant, platform, ecos.db, etc). Regarding ecos.db it is sometimes better to
> submit packages as plain text file rather than diff.
> 
> 2. I can notice some temporary files left by your editor. Please try to keep
> your code clean.
> 
> That's all for now.
> 
> 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1704|application/octet-stream    |text/plain
          mime type|                            |

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-22 17:34:01 BST ---
(In reply to comment #5)
> Hi Ilija
> 
> I sent the e-mail requested for the copyright assignment and I am waiting for
> their answer.

Thanks, then, let's begin and prepare your code for commit while paperware is
traveling.

> I updated the attachments :
> 
> - I move the common code to the variant level.
> 
> - I separated them as you recommended.
> 
> - I deleted the temporary files (sorry about that).
> 
> Also I figured out why I wasn't able to access some part of the flash. In fact
> speculation logic and cache aliasing (which are enable by default) are not
> supported on some tower boards. See there for more informations :
> http://forums.freescale.com/t5/Kinetis-ARM-Cortex-M4/Accessing-the-FLASH-causing-BUS-fault/m-p/78873#M509

Thank you for the pointer.

> 
> I added an option to disable these options in the cdl file. The driver should
> now work properly.

Good usage of eCos configureability.

I haven't yet tried the driver on target, here are some notes based on code
review.

First some formal notes:

I should have pointed this earlier (sory), here you will find some guidance how
to prepare eCos code:
http://ecos.sourceware.org/patches-criteria.html

That being said here are few notes:

Update ChangeLog in existing packages (i.e. Kinetis HAL) and add one to new
ones (the driver).

Convert tabs to spaces (tab size 4 is OK).

Make sure that Copyright banners are accurate. This includes year(s) in
Copyright line.

Line length should be typically less than 78 characters. This is a soft rule
but please try to reformat your code accordingly.

In file devs/flash/freescale/kinetis/current/src/kinetis_flash.c:

function kinetis_flash_init(): Your code seems correct, but FYI eCos provides a
set of hardware abstraction macros such as HAL_READ_UINT32() HAL_WRITE_UINT32()
for hardware abstraction. Device registers are typically accessed either
structured (as you do for cyghwr_hal_kinetis_flash_t) or by means of HAL macro.
Would you mind editing this part?

Example:

    cyg_uint32 regval;

    HAL_READ_UINT32(CYGHWR_HAL_KINETIS_FMC_PFB0CR, regval);
    regval &= ~CYGHWR_HAL_KINETIS_FMC_PFBCR_BIPE;
    HAL_WRITE_UINT32(CYGHWR_HAL_KINETIS_FMC_PFB0CR, regval);

Lines like following:
    CYGHWR_HAL_KINETIS_SIM_P->scgc6 |= 0x01UL;

There are macros for SCGS bit fields in var_io.h that you could use (If some
macro is missing feel free to add)

Note: FTFL clock is already being enabled during system init (all clock are)
but do not remove this line from FTFL driver, in some future upgrade all
drivers should have such and I intend to remove general clock enabling.

I guess that flashCommandSequence() could be static. eCos is being linked to
application(s) so let's keep exported names to minimum.

Could query[] be more general: "Freescale Kinetis internal flash" or "Kinetis
FTFL" ?

In file devs/flash/freescale/kinetis/current/src/kinetis_flash.h:

KINETIS_FLASH_BLOCK_SIZE: There are some devices with block size of 4KiB so it
should be configurable or inferred from device type. I have been informed that
there is some ambiguity in K60 devices as there are devices with both 2 KiB and
4 KiB block size, so to be on a safe side I would provide a CDL:

    cdl_option CYGNUM_DEVS_KINETIS_FLASH_BLOCK_SIZE {
        display "Block size"
        legal_values { 0 0x800 0x1000 }
        default_value 0
        description ".... 0 - Auto ...."
   }

In addition the platform HAL can override. Also check if some other value can
be configurable/inferred or read from Kinetis registers.

Regarding configuration options it would be good to cross-reference other
device manuals, typically K40 and K70 (that we have or will have soon in eCos).

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1702|                            |assignment?
               Flag|                            |

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1702|assignment?                 |
               Flag|                            |
   Attachment #1702|0                           |1
        is obsolete|                            |

--- Comment #7 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-02 08:38:44 BST ---
Created an attachment (id=1723)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1723)
Devs part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1703|0                           |1
        is obsolete|                            |

--- Comment #8 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-02 08:39:39 BST ---
Created an attachment (id=1724)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1724)
Hal part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #9 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-02 09:27:12 BST ---
(In reply to comment #6)

Hi Ilija,

If I am not mistaken, the last patches should implement what you pointed out.

For the block size thing, I did some quick research but it seems that there is
no way to know the size by reading registers. 
For the k60, it looks like 100Mhz devices have 2KB block size and 120,150 MHz
have 4KB block size.

It also looks like the block size has an impact on how to program the flash : I
use the program longword command in my driver for the k60 100 MHz but this
command doesn't exist in the k60 120 or 150 MHz.

Nicolas

> (In reply to comment #5)
> > Hi Ilija
> > 
> > I sent the e-mail requested for the copyright assignment and I am waiting for
> > their answer.
> 
> Thanks, then, let's begin and prepare your code for commit while paperware is
> traveling.
> 
> > I updated the attachments :
> > 
> > - I move the common code to the variant level.
> > 
> > - I separated them as you recommended.
> > 
> > - I deleted the temporary files (sorry about that).
> > 
> > Also I figured out why I wasn't able to access some part of the flash. In fact
> > speculation logic and cache aliasing (which are enable by default) are not
> > supported on some tower boards. See there for more informations :
> > http://forums.freescale.com/t5/Kinetis-ARM-Cortex-M4/Accessing-the-FLASH-causing-BUS-fault/m-p/78873#M509
> 
> Thank you for the pointer.
> 
> > 
> > I added an option to disable these options in the cdl file. The driver should
> > now work properly.
> 
> Good usage of eCos configureability.
> 
> I haven't yet tried the driver on target, here are some notes based on code
> review.
> 
> First some formal notes:
> 
> I should have pointed this earlier (sory), here you will find some guidance how
> to prepare eCos code:
> http://ecos.sourceware.org/patches-criteria.html
> 
> That being said here are few notes:
> 
> Update ChangeLog in existing packages (i.e. Kinetis HAL) and add one to new
> ones (the driver).
> 
> Convert tabs to spaces (tab size 4 is OK).
> 
> Make sure that Copyright banners are accurate. This includes year(s) in
> Copyright line.
> 
> Line length should be typically less than 78 characters. This is a soft rule
> but please try to reformat your code accordingly.
> 
> In file devs/flash/freescale/kinetis/current/src/kinetis_flash.c:
> 
> function kinetis_flash_init(): Your code seems correct, but FYI eCos provides a
> set of hardware abstraction macros such as HAL_READ_UINT32() HAL_WRITE_UINT32()
> for hardware abstraction. Device registers are typically accessed either
> structured (as you do for cyghwr_hal_kinetis_flash_t) or by means of HAL macro.
> Would you mind editing this part?
> 
> Example:
> 
>     cyg_uint32 regval;
> 
>     HAL_READ_UINT32(CYGHWR_HAL_KINETIS_FMC_PFB0CR, regval);
>     regval &= ~CYGHWR_HAL_KINETIS_FMC_PFBCR_BIPE;
>     HAL_WRITE_UINT32(CYGHWR_HAL_KINETIS_FMC_PFB0CR, regval);
> 
> Lines like following:
>     CYGHWR_HAL_KINETIS_SIM_P->scgc6 |= 0x01UL;
> 
> There are macros for SCGS bit fields in var_io.h that you could use (If some
> macro is missing feel free to add)
> 
> Note: FTFL clock is already being enabled during system init (all clock are)
> but do not remove this line from FTFL driver, in some future upgrade all
> drivers should have such and I intend to remove general clock enabling.
> 
> I guess that flashCommandSequence() could be static. eCos is being linked to
> application(s) so let's keep exported names to minimum.
> 
> Could query[] be more general: "Freescale Kinetis internal flash" or "Kinetis
> FTFL" ?
> 
> In file devs/flash/freescale/kinetis/current/src/kinetis_flash.h:
> 
> KINETIS_FLASH_BLOCK_SIZE: There are some devices with block size of 4KiB so it
> should be configurable or inferred from device type. I have been informed that
> there is some ambiguity in K60 devices as there are devices with both 2 KiB and
> 4 KiB block size, so to be on a safe side I would provide a CDL:
> 
>     cdl_option CYGNUM_DEVS_KINETIS_FLASH_BLOCK_SIZE {
>         display "Block size"
>         legal_values { 0 0x800 0x1000 }
>         default_value 0
>         description ".... 0 - Auto ...."
>    }
> 
> In addition the platform HAL can override. Also check if some other value can
> be configurable/inferred or read from Kinetis registers.
> 
> Regarding configuration options it would be good to cross-reference other
> device manuals, typically K40 and K70 (that we have or will have soon in eCos).
> 
> 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

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

--- Comment #10 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-02 16:12:44 BST ---
Hi Nicolas,

Does the fact you cancelled the request for assignment mean you have filled in
the paperwork and we just need to wait for the FSF? Or does it mean there will
not be a copyright assignment for this contribution after all?

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #11 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-02 16:18:27 BST ---
(In reply to comment #10)
> Hi Nicolas,
> 
> Does the fact you cancelled the request for assignment mean you have filled in
> the paperwork and we just need to wait for the FSF? Or does it mean there will
> not be a copyright assignment for this contribution after all?
> 
> Jifl

Hi Jifl,

Sorry if I cancelled the request for assignment, I did not do it on purpose.
The paperwork went to my manager (he was not available until now) and should
leave within the week.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #12 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-02 16:19:51 BST ---
Thanks Nicolas, that's fine, I just wanted to know what the situation was.
Thanks for contributing!

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #13 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-02 17:02:38 BST ---
(In reply to comment #12)
> Thanks Nicolas, that's fine, I just wanted to know what the situation was.
> Thanks for contributing!

Jifl

This unintentional cancellation seems to happen when the marked attachment is
being obsoleted.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #14 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-10 14:51:38 BST ---
Now that I have Redboot with flash support running in the k60, is there any
memory mapping configuration to make in order to be able to load an launch an
eCos app via Redboot ?
I tried to launch a SRAM startup type eCos application frome a ROM startup type
RedBoot application but without success.

Thanks for your help,

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #15 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-10 15:26:29 BST ---
(In reply to comment #14)
> Now that I have Redboot with flash support running in the k60, is there any
> memory mapping configuration to make in order to be able to load an launch an
> eCos app via Redboot ?
> I tried to launch a SRAM startup type eCos application frome a ROM startup type
> RedBoot application but without success.
> 
> Thanks for your help,
> 
> Nicolas

SRAM startup is intended for loading with JTAG. It does complete system
initialization as ROM startup (twr_k60n512_misc.c). For Redboot you need RAM
startup. I would recommend to look at TWR-K70F120M platform (just checked in)
for example. Probably you can make RAM startup with K60 SRAM alone but you may
have practical limitation with memory resources. We have built a Tower memory
module with FlexBus RAM (TWR-FXM) with which we can use Redboot.

I hope this helps
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned@bugs.ecos.source |ilijak@siva.com.mk
                   |ware.org                    |

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #16 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-15 07:22:07 BST ---
(In reply to comment #15)
> (In reply to comment #14)
> > Now that I have Redboot with flash support running in the k60, is there any
> > memory mapping configuration to make in order to be able to load an launch an
> > eCos app via Redboot ?
> > I tried to launch a SRAM startup type eCos application frome a ROM startup type
> > RedBoot application but without success.
> > 
> > Thanks for your help,
> > 
> > Nicolas
> 
> SRAM startup is intended for loading with JTAG. It does complete system
> initialization as ROM startup (twr_k60n512_misc.c). For Redboot you need RAM
> startup. I would recommend to look at TWR-K70F120M platform (just checked in)
> for example. Probably you can make RAM startup with K60 SRAM alone but you may
> have practical limitation with memory resources. We have built a Tower memory
> module with FlexBus RAM (TWR-FXM) with which we can use Redboot.
> 
> I hope this helps
> Ilija

Thanks for you answers.

I just receive an email from the FSF stating that my assignment is complete. Do
I need to do anything now ? 

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #17 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-15 09:42:15 BST ---
(In reply to comment #16)
[snip]
> 
> I just receive an email from the FSF stating that my assignment is complete. Do
> I need to do anything now ? 
> 
> Nicolas

Thank you for information Nicolas. Nothing else is required from you regarding
assignment. We are now expecting information from FSF...

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1723|                            |assignment+
               Flag|                            |

--- Comment #18 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-15 13:09:07 BST ---
(From update of attachment 1723)
I can confirm the assignment is now in place, dated yesterday.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #19 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-21 16:00:48 BST ---
Hi Nicolas

I'm trying to test the flash driver with Redboot but it seem there's some
problem. Instead of Redboot prompt I get some (probably) GDB stuff - I had to
apply the variant patch manually.

It may be due to configuration or because of recent Kinetis HAL upgrade.
Therefore I would ask you to sync the driver with current CVS and provide ECM
file(s) of your test configuration(s).

Regarding the code I have one remark. You already have a doubt where to put
CYG_FLASH_DRIVER, I would suggest a new file kinetis_flash.c in the same
directory with kinetis_misc.c (provided that it will be universal for all
Kinetis platforms).

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #20 from Nicolas Aujoux <nau@csm-instruments.com> 2012-05-29 07:53:11 BST ---
Hi Ilija,

I have made some tests and in order for the driver to work, I desactivated the
"Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
programming) and desactivated the "Keep Redboot configuration data in flash"
option.
When this options are enabled, Redboot try to read a portion of flash  (with a
memcpy) which leads to a problem.

I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
it to the file to be compile in the .cdl file. Redboot builds fine with it but
when I launch it, it seems that there is no flash init done. I'll keep working
on that but if you have any idea of what I am missing ...

Nicolas

(In reply to comment #19)
> Hi Nicolas
> 
> I'm trying to test the flash driver with Redboot but it seem there's some
> problem. Instead of Redboot prompt I get some (probably) GDB stuff - I had to
> apply the variant patch manually.
> 
> It may be due to configuration or because of recent Kinetis HAL upgrade.
> Therefore I would ask you to sync the driver with current CVS and provide ECM
> file(s) of your test configuration(s).
> 
> Regarding the code I have one remark. You already have a doubt where to put
> CYG_FLASH_DRIVER, I would suggest a new file kinetis_flash.c in the same
> directory with kinetis_misc.c (provided that it will be universal for all
> Kinetis platforms).
> 
> 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2012-06-20 08:48:42 BST ---
Hi Nicolas

I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
configuration data in FLASH bit it still raises exception. Can you post your
ECM file?

(In reply to comment #20)
> Hi Ilija,
> 
> I have made some tests and in order for the driver to work, I desactivated the
> "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> programming) and desactivated the "Keep Redboot configuration data in flash"
> option.
> When this options are enabled, Redboot try to read a portion of flash  (with a
> memcpy) which leads to a problem.

Have you tried with cyg_flash_read()? It is recommended in manual and I would
recommend too.

> 
> I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> it to the file to be compile in the .cdl file. Redboot builds fine with it but
> when I launch it, it seems that there is no flash init done. I'll keep working
> on that but if you have any idea of what I am missing ...

Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
linker since effectively there aren't references to it.
If the driver is general for all Kinetis devices you can leave it in
kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
Otherwise you can put copies in platforms (see STM32 for example). However
driver inclusion for compilation should be conditional with some #ifdef.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #22 from Nicolas Aujoux <nau@csm-instruments.com> 2012-06-20 15:11:16 BST ---
Created an attachment (id=1799)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1799)
Configuration file for a Redboot with flash working

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1799|application/octet-stream    |text/plain
          mime type|                            |

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #23 from Nicolas Aujoux <nau@csm-instruments.com> 2012-06-21 08:00:56 BST ---
(In reply to comment #21)
> Hi Nicolas
> 
> I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> configuration data in FLASH bit it still raises exception. Can you post your
> ECM file?

No problem. I posted a working for me configuration. I hope this works for you
as well.

> 
> (In reply to comment #20)
> > Hi Ilija,
> > 
> > I have made some tests and in order for the driver to work, I desactivated the
> > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > programming) and desactivated the "Keep Redboot configuration data in flash"
> > option.
> > When this options are enabled, Redboot try to read a portion of flash  (with a
> > memcpy) which leads to a problem.
> 
> Have you tried with cyg_flash_read()? It is recommended in manual and I would
> recommend too.

I found out something about that : it seems to come from th "Flash block
containing the directory" option which has the value "-1". This value should
correspond to the last block of flash but when I put the value to 2, I get a
prompt and the fis command (even if it still crash when I do a fis init).

> 
> > 
> > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > when I launch it, it seems that there is no flash init done. I'll keep working
> > on that but if you have any idea of what I am missing ...
> 
> Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> linker since effectively there aren't references to it.
> If the driver is general for all Kinetis devices you can leave it in
> kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> Otherwise you can put copies in platforms (see STM32 for example). However
> driver inclusion for compilation should be conditional with some #ifdef.

So I let it where it is for the moment. 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #24 from Ilija Kocho <ilijak@siva.com.mk> 2012-06-23 17:38:52 BST ---
(In reply to comment #23)
> (In reply to comment #21)
> > Hi Nicolas
> > 
> > I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> > configuration data in FLASH bit it still raises exception. Can you post your
> > ECM file?
> 
> No problem. I posted a working for me configuration. I hope this works for you
> as well.

Thanks. I did some testing.

> 
> > 
> > (In reply to comment #20)
> > > Hi Ilija,
> > > 
> > > I have made some tests and in order for the driver to work, I desactivated the
> > > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > > programming) and desactivated the "Keep Redboot configuration data in flash"
> > > option.
> > > When this options are enabled, Redboot try to read a portion of flash  (with a
> > > memcpy) which leads to a problem.
> > 

The end address in CYG_FLASH_DRIVER is 1 byte too high and it triggers
exception when you FIS directory and fconfig are at end of the FLASH.
It should be

(CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1)


Also I think that for the time being we should protect Redboot from overwriting
itself (and prevent writing to FLASH security area (0x400..0x40f). 
Note this can be the reason for your system freeze when you put FIS directory
at beginning of FLASH. Something like this:

#define REDBOOT_IMAGE_SIZE CYGBLD_REDBOOT_MIN_IMAGE_SIZE

cyg_kinetis_flash_dev hal_kinetis_flash_priv;
static const cyg_flash_block_info_t cyg_flash_kinetis_block_info[1] = {
    { KINETIS_FLASH_BLOCK_SIZE, (CYGMEM_REGION_flash_SIZE -
REDBOOT_IMAGE_SIZE)/
        KINETIS_FLASH_BLOCK_SIZE }};

CYG_FLASH_DRIVER(hal_kinetis_flash,
                 &cyg_kinetis_flash_funs,
                 0,
                 CYGMEM_REGION_flash + REDBOOT_IMAGE_SIZE,
                 (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
                 1, //number of block info
                 cyg_flash_kinetis_block_info,
                 &hal_kinetis_flash_priv);

With this configuration it works with default configuration. But I have tried
fconfig -i and fis init and it fails to write. Here is the "fconfig -i" minicom
output:

RedBoot> fconfig -i 
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Use BOOTP for network configuration: false
Gateway IP address: 192.168.209.1 
Local IP address: 192.168.209.77
Local IP address mask: 255.255.255.0
Default server IP address: 192.168.209.7
Console baud rate: 38400
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0x0007e000-0x0007efff: ..
... Program from 0x2000d800-0x2000e800 to 0x0007e000: V
Error writing config data at 0x0007e000: Data verify failed after operation


> 
> I found out something about that : it seems to come from th "Flash block
> containing the directory" option which has the value "-1". This value should
> correspond to the last block of flash but when I put the value to 2, I get a
> prompt and the fis command (even if it still crash when I do a fis init).
> 
> > 
> > > 
> > > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > > when I launch it, it seems that there is no flash init done. I'll keep working
> > > on that but if you have any idea of what I am missing ...
> > 
> > Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> > linker since effectively there aren't references to it.
> > If the driver is general for all Kinetis devices you can leave it in
> > kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> > Otherwise you can put copies in platforms (see STM32 for example). However
> > driver inclusion for compilation should be conditional with some #ifdef.
> 
> So I let it where it is for the moment. Thanks

For the time being you could leave it, but for the permanent 


> 
> > 
> > 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #25 from Nicolas Aujoux <nau@csm-instruments.com> 2012-06-26 10:31:10 BST ---
(In reply to comment #21)
> Hi Nicolas
> 
> I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> configuration data in FLASH bit it still raises exception. Can you post your
> ECM file?

No problem. I posted a working for me configuration. I hope this works for you
as well.

> 
> (In reply to comment #20)
> > Hi Ilija,
> > 
> > I have made some tests and in order for the driver to work, I desactivated the
> > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > programming) and desactivated the "Keep Redboot configuration data in flash"
> > option.
> > When this options are enabled, Redboot try to read a portion of flash  (with a
> > memcpy) which leads to a problem.
> 
> Have you tried with cyg_flash_read()? It is recommended in manual and I would
> recommend too.

I found out something about that : it seems to come from th "Flash block
containing the directory" option which has the value "-1". This value should
correspond to the last block of flash but when I put the value to 2, I get a
prompt and the fis command (even if it still crash when I do a fis init).

> 
> > 
> > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > when I launch it, it seems that there is no flash init done. I'll keep working
> > on that but if you have any idea of what I am missing ...
> 
> Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> linker since effectively there aren't references to it.
> If the driver is general for all Kinetis devices you can leave it in
> kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> Otherwise you can put copies in platforms (see STM32 for example). However
> driver inclusion for compilation should be conditional with some #ifdef.

So I let it where it is for the moment. Thanks

> 
> Ilija

(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #21)
> > > Hi Nicolas
> > > 
> > > I'm sorry for late reply, but I was busy. I tried to disable keeping Redboot
> > > configuration data in FLASH bit it still raises exception. Can you post your
> > > ECM file?
> > 
> > No problem. I posted a working for me configuration. I hope this works for you
> > as well.
> 
> Thanks. I did some testing.
> 
> > 
> > > 
> > > (In reply to comment #20)
> > > > Hi Ilija,
> > > > 
> > > > I have made some tests and in order for the driver to work, I desactivated the
> > > > "Redboot FIS support" (in Redboot ROM monitor -> Allow RedBoot tu support FLASH
> > > > programming) and desactivated the "Keep Redboot configuration data in flash"
> > > > option.
> > > > When this options are enabled, Redboot try to read a portion of flash  (with a
> > > > memcpy) which leads to a problem.
> > > 
> 
> The end address in CYG_FLASH_DRIVER is 1 byte too high and it triggers
> exception when you FIS directory and fconfig are at end of the FLASH.
> It should be
> 
> (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1)

Thanks for pointing that out. 

> 
> 
> Also I think that for the time being we should protect Redboot from overwriting
> itself (and prevent writing to FLASH security area (0x400..0x40f). 
> Note this can be the reason for your system freeze when you put FIS directory
> at beginning of FLASH. Something like this:
> 
> #define REDBOOT_IMAGE_SIZE CYGBLD_REDBOOT_MIN_IMAGE_SIZE
> 
> cyg_kinetis_flash_dev hal_kinetis_flash_priv;
> static const cyg_flash_block_info_t cyg_flash_kinetis_block_info[1] = {
>     { KINETIS_FLASH_BLOCK_SIZE, (CYGMEM_REGION_flash_SIZE -
> REDBOOT_IMAGE_SIZE)/
>         KINETIS_FLASH_BLOCK_SIZE }};
> 
> CYG_FLASH_DRIVER(hal_kinetis_flash,
>                  &cyg_kinetis_flash_funs,
>                  0,
>                  CYGMEM_REGION_flash + REDBOOT_IMAGE_SIZE,
>                  (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
>                  1, //number of block info
>                  cyg_flash_kinetis_block_info,
>                  &hal_kinetis_flash_priv);
> 
> With this configuration it works with default configuration. But I have tried
> fconfig -i and fis init and it fails to write. Here is the "fconfig -i" minicom
> output:
> 
> RedBoot> fconfig -i 
> Initialize non-volatile configuration - continue (y/n)? y
> Run script at boot: false
> Use BOOTP for network configuration: false
> Gateway IP address: 192.168.209.1 
> Local IP address: 192.168.209.77
> Local IP address mask: 255.255.255.0
> Default server IP address: 192.168.209.7
> Console baud rate: 38400
> GDB connection port: 9000
> Force console for special debug messages: false
> Network debug at boot time: false
> Update RedBoot non-volatile configuration - continue (y/n)? y
> ... Erase from 0x0007e000-0x0007efff: ..
> ... Program from 0x2000d800-0x2000e800 to 0x0007e000: V
> Error writing config data at 0x0007e000: Data verify failed after operation
> 

The problem here is that in my driver, I expect a relative address in flash so
I substract the flash base to the address and thus the program command actually
programs the address minus 0x20000. Anyway, my bad, I will post a patch to
correct this.

> 
> > 
> > I found out something about that : it seems to come from th "Flash block
> > containing the directory" option which has the value "-1". This value should
> > correspond to the last block of flash but when I put the value to 2, I get a
> > prompt and the fis command (even if it still crash when I do a fis init).
> > 
> > > 
> > > > 
> > > > I also try to move the CYG_FLASH_DRIVER into a new kinetis_flash.c file and add
> > > > it to the file to be compile in the .cdl file. Redboot builds fine with it but
> > > > when I launch it, it seems that there is no flash init done. I'll keep working
> > > > on that but if you have any idea of what I am missing ...
> > > 
> > > Probably the object file containing CYG_FLASH_DRIVER has been discarded by the
> > > linker since effectively there aren't references to it.
> > > If the driver is general for all Kinetis devices you can leave it in
> > > kinetis_misc.c or put it in kinetis_flash.inl and include in kinetis_misc.c.
> > > Otherwise you can put copies in platforms (see STM32 for example). However
> > > driver inclusion for compilation should be conditional with some #ifdef.
> > 
> > So I let it where it is for the moment. Thanks
> 
> For the time being you could leave it, but for the permanent 
> 
> 
> > 
> > > 
> > > 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1723|0                           |1
        is obsolete|                            |

--- Comment #26 from Nicolas Aujoux <nau@csm-instruments.com> 2012-06-28 08:56:07 BST ---
Created an attachment (id=1806)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1806)
Devs part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1724|0                           |1
        is obsolete|                            |

--- Comment #27 from Nicolas Aujoux <nau@csm-instruments.com> 2012-06-28 08:56:45 BST ---
Created an attachment (id=1807)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1807)
Hal part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #28 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-10 10:02:21 BST ---
Created an attachment (id=1819)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1819)
K60 Redboot-Flash ECM file

Hi Nicolas

(In reply to comment #27)
> Created an attachment (id=1807)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1807) [details]
> Hal part of the patch

I have tested it at seems to work. With attached ECM applied I could use "fis
init" and "fconfig -f".

There's, however, one limitation - we can't write to the flash bank that
contains Redboot itself. This is easily achieved by placing
flashCommandSequence() in RAM (only one function goes to RAM - good software
design :) ).

eCos has provision for this with ".2ram" memory section(s). You just need to
add the __attribute__ to the function declaration:

-- Code snippet ---
static int flashCommandSequence(cyg_uint8, cyg_uint8*) __attribute__((section
(".2ram.flashCommandSequence")));

-- snippet end ---

Now that we have it working, you can remove REDBOOT_IMAGE_SIZE macro as fis
will recognize and reserve the Redboot area.
Note: Flash configuration record 0x400-0x40f still must be protected from
accidental writing.

-- Code snippet ---

CYG_FLASH_DRIVER(hal_kinetis_flash,
                 &cyg_kinetis_flash_funs,
                 0,
                 CYGMEM_REGION_flash,
                 (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
                 1,        //number of block info
                 cyg_flash_kinetis_block_info,
                 &hal_kinetis_flash_priv);

-- snippet end

Next things we should address are support for other parts: K40, K70 and
automatic Flash type/size recognition.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1806|0                           |1
        is obsolete|                            |

--- Comment #29 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-10 14:20:44 BST ---
Created an attachment (id=1820)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1820)
Devs part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1807|0                           |1
        is obsolete|                            |

--- Comment #30 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-10 14:21:17 BST ---
Created an attachment (id=1821)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1821)
Hal part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #31 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-10 14:24:46 BST ---
Hi Ilija,

Thank you for your help. I move the function into RAM as you mentionned and it
works well. 
I added the patches that implement this functionnality and remove the flash
limitation.

Nicolas

(In reply to comment #28)
> Created an attachment (id=1819)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1819) [details]
> K60 Redboot-Flash ECM file
> 
> Hi Nicolas
> 
> (In reply to comment #27)
> > Created an attachment (id=1807)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1807) [details]
[details]
> > Hal part of the patch
> 
> I have tested it at seems to work. With attached ECM applied I could use "fis
> init" and "fconfig -f".
> 
> There's, however, one limitation - we can't write to the flash bank that
> contains Redboot itself. This is easily achieved by placing
> flashCommandSequence() in RAM (only one function goes to RAM - good software
> design :) ).
> 
> eCos has provision for this with ".2ram" memory section(s). You just need to
> add the __attribute__ to the function declaration:
> 
> -- Code snippet ---
> static int flashCommandSequence(cyg_uint8, cyg_uint8*) __attribute__((section
> (".2ram.flashCommandSequence")));
> 
> -- snippet end ---
> 
> Now that we have it working, you can remove REDBOOT_IMAGE_SIZE macro as fis
> will recognize and reserve the Redboot area.
> Note: Flash configuration record 0x400-0x40f still must be protected from
> accidental writing.
> 
> -- Code snippet ---
> 
> CYG_FLASH_DRIVER(hal_kinetis_flash,
>                  &cyg_kinetis_flash_funs,
>                  0,
>                  CYGMEM_REGION_flash,
>                  (CYGMEM_REGION_flash + CYGMEM_REGION_flash_SIZE - 1),
>                  1,        //number of block info
>                  cyg_flash_kinetis_block_info,
>                  &hal_kinetis_flash_priv);
> 
> -- snippet end
> 
> Next things we should address are support for other parts: K40, K70 and
> automatic Flash type/size recognition.
> 
> 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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #32 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-10 16:47:11 BST ---
Hi Nicolas

(In reply to comment #31)
> Hi Ilija,
> 
> Thank you for your help. I move the function into RAM as you mentionned and it
> works well. 
> I added the patches that implement this functionnality and remove the flash
> limitation.
> 

Thank you for update.

Now that we have it working, let's prepare it for commit:

1. We don't want CYGNUM_DEVS_KINETIS_FLASH_LOGIC_ERROR_BUG work-around to ruin
the FLASH performance in normal operation, therefore it should be applied only
during the critical sections (write, erase, etc.). You can write inline
functions/macros that enable/disable it and call them where necessary.

2. Some protection of flash configuration area 0x400-0x40f. Let's think about
it.

3. Automatic block size determination. The default value should be derived from
the part type if possible. Also, the flash init function should check this
value against the real silicon (based on part Id, etc).

Should you may additional questions/comments esp. on 2. and 3. feel free to
ask.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #33 from Jonathan Larmour <jifl@ecoscentric.com> 2012-07-11 06:13:40 BST ---
Hi Nicolas,

As well as Ilija's comments, I also have a few comments too before this is
committed:

- The Flash package needs a ChangeLog file

- The whitespace could be tidied a little in the CDL file. Just line things up
and so on.

- There's an unnecessary couple of blank lines added in var_io.h just at the
end of the FMC definitions.

- Do not include pkgconf/redboot.h. RedBoot is not the only thing that can use
the flash driver.

- I don't think the flash driver should be instantiated in kinetis_misc.c. It
should either go in kinetis_flash.c along with everything else, or go in
individual platform HALs, to allow them the ability to override or disable
(like the STM32 does with its internal flash driver).

- The cyg_kinetis_flash_dev structure can be completely empty. Its contents are
not needed unless you are dynamically working out the sizes like the STM32 does
(see below).

- There's no need to re-declare hal_kinetis_flash_conf_p in kinetis_flash.c.
Just include var_io.h.

- kinetis_flashEraseAllBlocks and kinetis_flashEraseBlock are not used. They
should be either removed or put in #if 0 to silence warnings.

Although if you do want to keep flashEraseBlock, then I suggest checking the
requested address is block aligned first.

- I know you copied kinetis_flash_query() from somewhere else (STM32), but
nevertheless the query string can be 'const' (which the STM32 driver should
have as well). And add the 'e' onto 'Freescal'. Or better still, just use
something shorter like "Internal" or "On-chip", to save a little flash.
Also it would seem better to change this:
    memcpy( data, query, sizeof(query));
to:
    if ( sizeof(query) < len )
        len = sizeof(query);
    memcpy( data, query, len );

- In flashCommandSequence(), please either add a comment on the empty while
loops, or use CYG_EMPTY_STATEMENT; instead.

- In response to Ilija's comments, for his point (2) I don't think there's
anything that can sensibly be done. All flash drivers run the risk of messing
things up so you can't boot the board. And for his point (3), I agree it would
be better to make it more like the STM32 driver, and work things out from the
part. Although I disagree with Ilija and wouldn't say to check it against the
hardware (unless CYGPKG_INFRA_DEBUG is defined maybe).

Thanks for working through this and contributing Nicolas!

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #34 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-11 08:12:14 BST ---
Hi Jifl

Thanks for comments.

(In reply to comment #33)
> Hi Nicolas,
> 
> As well as Ilija's comments, I also have a few comments too before this is
> committed:
> 

[snip]
.
> 
> - I don't think the flash driver should be instantiated in kinetis_misc.c. It
> should either go in kinetis_flash.c along with everything else, or go in
> individual platform HALs, to allow them the ability to override or disable
> (like the STM32 does with its internal flash driver).
> 

FAOD I guess you are referring to devs/____/kinetis_flash.c . (Because there
was a version with another kinetis_flash.c in HAL that contained only the flash
driver entry. It was abandoned for reasons stated in comment #21).
I vote for putting the driver entry with driver code since I don't see a need
for different instances.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-11 12:42:07 BST ---
(In reply to comment #33)
> 
> - In response to Ilija's comments, for his point (2) I don't think there's
> anything that can sensibly be done. All flash drivers run the risk of messing
> things up so you can't boot the board.

On Kinetis writing the flash configuration record can be really devastating. It
is possible to lock the flash permanently. I think we can add a CDL option so
the user will have to explicitly enable writing to this record (either always,
or in case if the bit-string is "dangerous").


> And for his point (3), I agree it would
> be better to make it more like the STM32 driver, and work things out from the
> part. Although I disagree with Ilija and wouldn't say to check it against the
> hardware (unless CYGPKG_INFRA_DEBUG is defined maybe).

It could also be a user option.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #36 from Jonathan Larmour <jifl@ecoscentric.com> 2012-07-11 15:41:14 BST ---
(In reply to comment #35)
> (In reply to comment #33)
> > 
> > - In response to Ilija's comments, for his point (2) I don't think there's
> > anything that can sensibly be done. All flash drivers run the risk of messing
> > things up so you can't boot the board.
> 
> On Kinetis writing the flash configuration record can be really devastating. It
> is possible to lock the flash permanently. I think we can add a CDL option so
> the user will have to explicitly enable writing to this record (either always,
> or in case if the bit-string is "dangerous").

Okay, in that case, that does sound like a relevant thing to handle. We could
add special kinetis-specific functions to enable writes to that region for when
they are genuinely required, but if we did, it would never be possible to
manage this area from RedBoot for example.

So I suggest subverting the existing locking system. In other words, implement
the CYGHWR_IO_FLASH_BLOCK_LOCKING CDL interface and provide lock/unlock
functions. Then just keep a cyg_bool in the driver's private data to indicate
whether this region is already locked or unlocked (and default to locked), and
which the lock/unlock functions control.

> > And for his point (3), I agree it would
> > be better to make it more like the STM32 driver, and work things out from the
> > part. Although I disagree with Ilija and wouldn't say to check it against the
> > hardware (unless CYGPKG_INFRA_DEBUG is defined maybe).
> 
> It could also be a user option.

True, defaulting to CYGPKG_INFRA_DEBUG. But that might be unnecessary
complication. Depends on what Nicolas or whoever works on this feels like doing
I guess :-). All I'm saying is that this sort of check is more appropriate for
debug, than production, and we should be as careful as possible with footprint
on Cortex-M.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1001623

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1821|0                           |1
        is obsolete|                            |

--- Comment #38 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-18 15:11:40 BST ---
Created an attachment (id=1832)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1832)
Hal part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1820|0                           |1
        is obsolete|                            |

--- Comment #37 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-18 15:10:39 BST ---
Created an attachment (id=1831)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1831)
Devs part of the patch

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #39 from Nicolas Aujoux <nau@csm-instruments.com> 2012-07-18 15:28:26 BST ---
(In reply to comment #38)
> Created an attachment (id=1832)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1832) [details]
> Hal part of the patch

Hello Ilija and Jifl,

I updated the two patches with some modifications (but not all) :
 * I think I have made pretty much all the list of Jifl.
 * I have made the modifications for the first point of Ilija  (regarding flash
performance). For this feature, I had to create a flash_read function.
Otherwise, the flash was read without calling the kinetis flash driver and
therefore without the optimisation disabled, causing errors. Don't know if this
is the right way to do it but it works like that.

So there is still work to do on Ilija's point 2 and 3.

As I told to Ilija, I will not be working in my current company anymore so I
will not be able to work on this project. 
Nonetheless, others will work on this (notably Pierre-Jean Coudert, whom you 
already spock with) and will ask for a copyright assignment if they need to.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-20 12:25:31 BST ---
Hi Nicolas

Thank you for the update.

(In reply to comment #39)
> (In reply to comment #38)
> > Created an attachment (id=1832)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1832) [details]
[details]
> > Hal part of the patch
> 
> Hello Ilija and Jifl,
> 
> I updated the two patches with some modifications (but not all) :
>  * I think I have made pretty much all the list of Jifl.
>  * I have made the modifications for the first point of Ilija  (regarding flash
> performance). For this feature, I had to create a flash_read function.
> Otherwise, the flash was read without calling the kinetis flash driver and
> therefore without the optimisation disabled, causing errors. Don't know if this
> is the right way to do it but it works like that.

It is actually a FMC _feature_ and there is a request that all writings in FMC
registers be done by code _not_ executing in flash. Ref: a note in: / 27.4(K60)
or 29.4(K70) Memory map and register descriptions /.

I would replace "optimization" with "acceleration". "Optimization" may be
associated with code optimizations - by compiler or handicraft while
"acceleration" is widely used for hardware that speeds up execution of flashed
code. Although FS doesn't use the term flash accelerator in their manuals
Cortex-M users should be familiar (NXP, ST). If you lack a time for new patches
I can do the changes.

> 
> So there is still work to do on Ilija's point 2 and 3.

Having in mind Jifl's comments probably point 2 can be put in TODO status. 3
too.

> 
> As I told to Ilija, I will not be working in my current company anymore so I
> will not be able to work on this project. 
> Nonetheless, others will work on this (notably Pierre-Jean Coudert, whom you 
> already spock with) and will ask for a copyright assignment if they need to.

To be on a safe side, copyright assignment, especially employer's disclaimer,
is recommended even for small patches and mandatory for substantial.

Should you contribute in eCos from your new job, we shall need a disclaimer
from your new employer.

Once again, thank you for contributing to eCos and I wish you fun and success
at your new job.

Live long and prosper.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1831|0                           |1
        is obsolete|                            |

--- Comment #41 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-07 14:16:10 BST ---
Created an attachment (id=1875)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1875)
Kinetis Flash device driver 120807

Hi Nicolas (if you are still receiving this mail) and others.

In absence of Nicolas I took a liberty to add 4K sector support, as I need it
for K70. (I hope his colleagues will accomplish Copyright assignment and carry
on soon).
In a course of adding K70 support I found out that it is possible to write FTFL
registers freely so I optimized a code little bit. Other than that it is the
same code.

Here I submit the driver.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1832|0                           |1
        is obsolete|                            |

--- Comment #42 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-07 14:18:56 BST ---
Created an attachment (id=1876)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1876)
Kinetis Flash HAL 120807

This is essentially same as Attachment 1832.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #43 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-07 14:23:36 BST ---
(In reply to comment #41)
> Created an attachment (id=1875)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1875) [details]
> Kinetis Flash device driver 120807
> 
> Hi Nicolas (if you are still receiving this mail) and others.
> 
> In absence of Nicolas I took a liberty to add 4K sector support, as I need it
> for K70. (I hope his colleagues will accomplish Copyright assignment and carry
> on soon).
> In a course of adding K70 support I found out that it is possible to write FTFL
> registers freely so I optimized a code little bit. Other than that it is the
> same code.
> 
> Here I submit the driver.

BTW, I also added cache support needed for 120/150 MHz devices.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #44 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-24 15:34:03 BST ---
Kinetis flash driver has been on test in SIvA for a while and seems stable. I
have proved it to work on TWR-K60N512, TWR-K70F120M, TWR-K40X256 and Kwikstik
targets.

If there aren't objections by tomorrow (2012.09.25) I am going to commit.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #45 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-25 17:22:42 BST ---
Hi Ilija,

After my summer holidays, I've been exceptionally busy for various reasons,
sorry about that. But before you commit here...

There's no way to disable the flash driver. Once you add CYGPKG_IO_FLASH this
driver will be present even if you don't want to use it, e.g. to only support
off-chip flash. Not impossible if you want to keep on-chip flash for your
program and off-chip for data (e.g. flash filesystem).

I assume you are happy leaving the flash configuration area unprotected for
now?

We could temporarily do something crude and specifically check for the
0x400-0x40f addresses and have a CDL option (default on) which refuses to
program that area. Someone would have to disable the CDL option to program
them. Not as sophisticated as what I suggested first of all, but perhaps a
safety net?

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1875|0                           |1
        is obsolete|                            |

--- Comment #46 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-25 21:17:29 BST ---
Created an attachment (id=1940)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1940)
Kinetis Flash device driver 120925

(In reply to comment #45)

Hi Jifl,
Many thanks for your comments.

> Hi Ilija,
> 
> After my summer holidays, I've been exceptionally busy for various reasons,
> sorry about that. But before you commit here...

I hope you had nice holidays. I was busy as well past few weeks and now I'm
trying to fight the backlog.

> 
> There's no way to disable the flash driver. Once you add CYGPKG_IO_FLASH this
> driver will be present even if you don't want to use it, e.g. to only support
> off-chip flash. Not impossible if you want to keep on-chip flash for your
> program and off-chip for data (e.g. flash filesystem).

Thank you for pointing this out, I wasn't aware of this. Btw, can't application
select where will FS reside in runtime?

Anyway, I attach a solution (not tested yet). The realisation is somehow
different than in STM32 but should be functionally equivalent. Is there some
severe reason for tab entry to live with HAL rather than driver? Also, maybe
#ifdef could enclose complete driver code.

> 
> I assume you are happy leaving the flash configuration area unprotected for
> now?

I gave up due to lack of RedBoot user control (that you have pointed out).
Also, during practical use I realised that attempt for rewriting is pretty much
unlikely, because the critical bytes are within RedBoot area.

Btw, maybe we could consider RedBoot protecting itself from overwriting, in
general (CDL option). Then, the critical functions: /fis load/, etc. could have
-f option to enforce writing in critical regions.

> 
> We could temporarily do something crude and specifically check for the
> 0x400-0x40f addresses and have a CDL option (default on) which refuses to
> program that area. Someone would have to disable the CDL option to program
> them. Not as sophisticated as what I suggested first of all, but perhaps a
> safety net?

I could look at this, but I realize it would need some printouts..., so I would
rather think about general RedBoot solution above.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1940|0                           |1
        is obsolete|                            |

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #47 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-26 13:29:50 BST ---
Created an attachment (id=1941)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1941)
Kinetis Flash device driver 120926

Now CYGHWR_HAL_CORTEXM_KINETIS_FLASH controls driver compilation. Since there
will be maximum one instance of internal flash, we can omit complete driver
code when not needed.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #48 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-26 15:41:56 BST ---
Hi Ilija,

Thanks for that. Unfortunately I've just noticed another issue (sorry!), but
it's an important one to be resolved. There are calls to HAL_DCACHE_DISABLE().
But if the dcache is in writeback mode, you need to flush any dirty cache lines
to memory, so a call to HAL_DCACHE_SYNC() is needed.

And, as you'll probably have seen elsewhere in eCos, because of the risk of an
interrupt coming in and creating more dirty cache lines after the sync but
before the disable, you also need to disable interrupts around it. And you also
need to allow for the cache already having been disabled (otherwise you may
flush lines to memory which aren't actually valid for what's running).

So in other words, you should have something like this:

static void __attribute__((__long_call__))
cache_off( cyg_uint32 *cachestate ) {
    cyg_uint32 intstate, dcachestate, icachestate;

    HAL_DISABLE_INTERRUPTS(intstate); 
    HAL_DCACHE_IS_ENABLED(dcachestate);
    HAL_ICACHE_IS_ENABLED(icachestate);
    *cachestate = (dcachestate?1:0) | (icachestate?2:0);
    if (dcachestate) {
        HAL_DCACHE_SYNC();
        HAL_DCACHE_DISABLE();
    }
    if (icachestate) {
        HAL_ICACHE_DISABLE();
    }
    HAL_RESTORE_INTERRUPTS(intstate);
#ifdef CYGNUM_DEVS_KINETIS_FLASH_LOGIC_ERROR_BUG
    disable_flash_optimisation();
#endif
}

You might also need a HAL_DCACHE_INVALIDATE_ALL() after the sync, before the
disable, depending on whether the kinetis cache will still look at cache lines
marked as valid in the cache, even when disabled (it may seem like it shouldn't
but some cache architectures do do that!). Ditto for the icache.

Given the separate cache_on/cache_off functions, you need the extra argument to
pass around the cache state instead.

To restore, for the Kinetis you probably don't need to disable interrupts I
think because IIRC it doesn't do anything which would be a problem on
interruption, so:

static void __attribute__((__long_call__))
cache_on( cyg_uint32 *cachestate ) {
#ifdef CYGNUM_DEVS_KINETIS_FLASH_LOGIC_ERROR_BUG
    enable_flash_optimisation();
#endif
    if (*cachestate & 1)
        HAL_DCACHE_ENABLE();
    if (*cachestate & 2)
        HAL_ICACHE_ENABLE();
}

Hopefully at least I've given enough code that this is an easy change for you
to try out (since I don't have hardware :-)).

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #49 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-26 16:48:50 BST ---
(In reply to comment #46)
> > After my summer holidays, I've been exceptionally busy for various reasons,
> > sorry about that. But before you commit here...
> 
> I hope you had nice holidays. I was busy as well past few weeks and now I'm
> trying to fight the backlog.

A battle I wish I could win!

> > There's no way to disable the flash driver. [snip]Not impossible if
> > you want to keep on-chip flash for your
> > program and off-chip for data (e.g. flash filesystem).
> 
> Thank you for pointing this out, I wasn't aware of this. Btw, can't
> application select where will FS reside in runtime?

Yes, but if the only flash driver support you need is for external flash, the
driver for internal flash isn't needed and is just taking up code space.

> Anyway, I attach a solution (not tested yet). The realisation is somehow
> different than in STM32 but should be functionally equivalent. Is there some
> severe reason for tab entry to live with HAL rather than driver? Also, maybe
> #ifdef could enclose complete driver code.

The reason is has lived in HALs on other platforms is to keep all the flash
driver options in the same place in the configuration tree, whether that be for
on-chip flash or off-chip flash. It's not a big deal.

> > We could temporarily do something crude and specifically check for the
> > 0x400-0x40f addresses and have a CDL option (default on) which refuses to
> > program that area. Someone would have to disable the CDL option to program
> > them. Not as sophisticated as what I suggested first of all, but perhaps a
> > safety net?
> 
> I could look at this, but I realize it would need some printouts..., so I would
> rather think about general RedBoot solution above.

Sure, whatever you feel comfortable with.

I also found another major problem with your previous patch. There's no
trailing newline on the last line of the ChangeLog file. Luckily no-one has
been killed. ;-)

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #50 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-27 09:06:22 BST ---
(In reply to comment #48)

Thank you for the code Jifl, I tested it on K70/RedBoot (i.e. without
interrupts) and it works.

Mentioning the cache reminded me about our on-going discussion in Bug #1001606.
(Btw, recently I made a post on my experiments regarding separate/unified
caches issue <http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001606#c17>).
The conclusion of this discussion may affect this driver (I hope it won't stale
the driver for long). Namely, provided that we treat caches as unified (as it
is at present), the HAL_ICACHE*() calls are redundant (though harmless) as they
mirror respective HAL_DCACHE*() macros that call functions operating on both PS
and PC caches. 

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1941|0                           |1
        is obsolete|                            |

--- Comment #51 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-27 19:26:00 BST ---
Created an attachment (id=1942)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1942)
Kinetis Flash device driver 120926-2017 - Separate D and I caches.

(In reply to comment #48)
Hi Jifl.

Here is a patch with your original code. Applicable with both separate and
unified caches. Tested on TWR-K70F120M (device with cache) and TWR-K60N512
(cache-less device)

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #52 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-27 19:29:04 BST ---
Created an attachment (id=1943)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1943)
Kinetis Flash device driver 120927 - Unified caches.

(In reply to comment #48)
Hi Jifl.

Here is a patch with code optimised for unified cache.
Tested on TWR-K70F120M (device with cache) and TWR-K60N512 (cache-less device)

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1943|0                           |1
        is obsolete|                            |

--- Comment #53 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-27 19:39:14 BST ---
Created an attachment (id=1944)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1944)
Kinetis Flash device driver 120927 - Unified caches.

Previous patch (Attachment #1943) somehow got corrupted. This one is hopefully
OK.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #54 from Jonathan Larmour <jifl@ecoscentric.com> 2012-09-28 17:15:19 BST ---
Patch looks fine to me. You can whichever version you think is appropriate, but
the outcome of bug 1001606 will presumably dictate which. I don't have time to
look at bug 1001606 today, but will try to next week.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #55 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-28 20:05:43 BST ---
(In reply to comment #54)
> Patch looks fine to me. You can whichever version you think is appropriate, but
> the outcome of bug 1001606 will presumably dictate which. I don't have time to
> look at bug 1001606 today, but will try to next week.

Yes, we can say that this bug pretty much depends on resolution in 1001606.
CU.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1799|0                           |1
        is obsolete|                            |
   Attachment #1819|0                           |1
        is obsolete|                            |
   Attachment #1942|0                           |1
        is obsolete|                            |
   Attachment #1944|0                           |1
        is obsolete|                            |

--- Comment #56 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-04 14:32:51 GMT ---
Created an attachment (id=1974)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1974)
Kinetis Flash device driver 121104

This is split-cache version synchronized with latest Kinetis cache update.
Tested and checked in.

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1876|0                           |1
        is obsolete|                            |

--- Comment #57 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-04 14:34:04 GMT ---
Created an attachment (id=1975)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1975)
Kinetis HAL variant 121104

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #58 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-04 14:35:11 GMT ---
Created an attachment (id=1976)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1976)
Kinetis HAL TWR-K70F120M 121104

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1704|0                           |1
        is obsolete|                            |

--- Comment #59 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-04 14:36:03 GMT ---
Created an attachment (id=1977)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1977)
ecos.db diff 121104

-- 
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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

--- Comment #60 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-04 14:39:14 GMT ---
Checked in.
Many thanks to Nicolas Aujoux for the contribution.

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 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

Ilija Kocho <ilijak@siva.com.mk> changed:

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

--- Comment #61 from Ilija Kocho <ilijak@siva.com.mk> ---
Already checked in, marking resolved.

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

[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board

[bugzilla-daemon]

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

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

Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
      Custom Target|                            |Kinetis

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