This is the mail archive of the
mailing list for the eCos project.
[Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Wed, 26 Sep 2012 16:48:54 +0100
- Subject: [Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board
- Auto-submitted: auto-generated
- References: <email@example.com/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #49 from Jonathan Larmour <firstname.lastname@example.org> 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. ;-)
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.