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

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

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.