This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Please do not reply to this email. Use the web interface provided at:

Ilija Kocho <> changed:

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

--- Comment #46 from Ilija Kocho <> 2012-09-25 21:17:29 BST ---
Created an attachment (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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]