From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1739 invoked by alias); 18 Jun 2006 05:14:24 -0000 Received: (qmail 1731 invoked by uid 22791); 18 Jun 2006 05:14:23 -0000 X-Spam-Check-By: sourceware.org Received: from potter.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 18 Jun 2006 05:14:22 +0000 Received: (qmail 3200 invoked from network); 18 Jun 2006 05:14:20 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jun 2006 05:14:20 -0000 To: Mark Kettenis Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: <200606171959.k5HJxABZ003460@elgar.sibelius.xs4all.nl> From: Jim Blandy Date: Sun, 18 Jun 2006 09:55:00 -0000 In-Reply-To: <200606171959.k5HJxABZ003460@elgar.sibelius.xs4all.nl> (Mark Kettenis's message of "Sat, 17 Jun 2006 21:59:10 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00120.txt.bz2 Mark Kettenis writes: >> From: Jim Blandy >> Date: Tue, 23 May 2006 16:32:42 -0700 >> >> One of the problems GDB has in the embedded development world is its >> lack of support for loading programs into flash memory. After some >> conversation amongst ourselves to weed out patently stupid stuff (none >> of the text below is mine... hey), we at CodeSourcery put together the >> following proposal for general comments and criticism. >> >> We'd like to reach consensus on what the user interface should be >> before we worry about implementation details --- possible remote >> protocol changes, and so on --- so let's leave those topics aside for >> the time being. >> >> What do folks think? > > I don't think the gdb user interface should depend on the sort of > memory you're targeting, i.e. the interface should be the same for all > memory whether it is RAM, EEPROM or flash. So I think "write-flash" > is the the wrong name for the command. > > Looks like what you really want is some sort of command to (partially) > write-protect (parts of) memory. Write-flash isn't the name of the command; that's just the name of the setting which controls whether we treat attempts to mutate variables in flash as errors or not. The command for loading programs remains 'load', regardless of the type of memory being accessed. We really don't want to allow single-variable writes by default, since writing to a variable in flash could take tens of seconds on some devices. But loading programs into flash is a common operation, just as common as using 'load' in ordinary development. So what we want is read-onlyness depending on the command used. And we also want the read-onlyness map pre-initialized to match the areas of flash on the target, since the point is to warn people before attempting expensive operations. I think the useful semantics here are pretty flash-specific.