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

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #37 from Nicolas Aujoux <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #38 from Nicolas Aujoux <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #41 from Ilija Kocho <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #42 from Ilija Kocho <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #46 from Ilija Kocho <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #51 from Ilija Kocho <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-daemon
In reply to this post by 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 <[hidden email]> changed:

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

--- Comment #53 from Ilija Kocho <[hidden email]> 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.
1234