From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18894 invoked by alias); 23 May 2006 23:32:46 -0000 Received: (qmail 18845 invoked by uid 22791); 23 May 2006 23:32:45 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 May 2006 23:32:44 +0000 Received: (qmail 21729 invoked from network); 23 May 2006 23:32:42 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 May 2006 23:32:42 -0000 To: gdb@sourceware.org Subject: GDB support for Flash memory programming From: Jim Blandy Date: Wed, 24 May 2006 01:44:00 -0000 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-05/txt/msg00343.txt.bz2 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? --- Background Flash memory is a popular form of non-volatile memory. When reading, it is byte-addressable, like traditional RAM or ROM. An entire block (many kilobytes, typically) of flash can be erased with a single command. Individual bytes can be written only if they have been erased, but not subsequently written. Therefore, to write a single byte, without changing other bytes in the same block, one must read the block, erase the block, and then re-write the block using the previously read data, as modified by the intended write. Flash is typically used for program storage. On some systems, flash is in fact the only place to store programs. For example, some systems have have relatively large amounts of flash, but very small amounts of RAM. If the flash memory controller has a JTAG interface (most do) then the flash memory can typically be programmed using the same ICE/BDM unit that is used for debugging. Because GDB already communicates with these ICE units (typically via a GDB stub), and because GDB already supports loading programs onto embedded systems (via the load command), it is natural that GDB support loading programs into flash memory as well. This document proposes a GDB user interface for loading programs into flash memory. In what follows, the term "GDB" refers to the user's view of GDB, which includes GDB, any applicable stub, the ICE units, etc. Thus statements like "GDB must do X" are not meant to imply that GDB proper must do X, but rather that GDB must cause X to occur. Program Images If the program image loaded by the load command will result in any portion of the program image being placed in flash memory, then GDB is responsible for modifying the flash accordingly. GDB must not modify bytes outside of the program image itself. Therefore, if the program image occupies only a portion of a flash sector, GDB is responsible for arranging flash read/erase/write commands appropriately so as to avoid changing unmodified portions of the sector. If the target hardware requires any other modifications to special memory addresses (such as placing the initial value of the program counter at a specified address), then it is the responsibility of the programmer to ensure that the program image contains appropriate values at those addresses; GDB's responsibility is simply to accurately copy the program image to the target. The rationale for using load (rather than an alternative flash command) is that, on a system in which programs are located in flash, loading a program implies placing it in flash. Furthermore, GUIs, scripts, etc., that use load (or the MI equivalent thereof) will not require change to work with flash systems. Variables and Data By default, variables and other data located in flash may not be modified by the user, other than by use of the load command. For example, if i is located in flash, then: set var i = 10 will result in an error message. (As a consequence, GDB must be able to determine which addresses lie in flash; otherwise, GDB, using a stub with a 100% transparent interface to flash, would not be able to issue an error.) The rationale for forbidding modification of variables is that most such attempted modifications probably represent user error. Furthermore, because setting a single variable requires erasing and writing an entire flash sector, there might be some noticable delay in implementing this request. Customization GDB will have a new write-flash variable. This variable will have three possible states: * on All writes to flash, including those to variables/data, are permitted. This mode may be used to permit explicit "poke" operations, like the assignment above. * load The load command may write to flash; no other commands may write to flash. This mode is the default. * off No commands may write to flash. This mode may be used for safety when debugging a production system.