From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6549 invoked by alias); 11 Jul 2012 14:41:34 -0000 Received: (qmail 6536 invoked by uid 22791); 11 Jul 2012 14:41:32 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jul 2012 14:41:19 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 78DB82F780CA for ; Wed, 11 Jul 2012 15:41:18 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8U6JvnvV94w; Wed, 11 Jul 2012 15:41:17 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001561] Internal flash driver for Freescale TWR-K60N512 board X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jifl@ecoscentric.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: ilijak@siva.com.mk X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 11 Jul 2012 14:41:00 -0000 Message-Id: <20120711144117.54F012F78024@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2012-07/txt/msg00012.txt.bz2 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 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.