CELF Project Proposal/Create tool to edit ihex or srec files

Summary 

Upgrade an existing Hex editor to be able to read/write Intel Hex and Motorola S-record files

Proposer 

Frieder Ferlemann

Description

The ihex and srec formats can have an important role in an embedded developers toolchain. The formats specify both the addresses and the corresponding data, thus allowing to specify specific ranges of data which are to be modified. While editors for binary files exist for linux they all seem to lack import and export functionality for these formats.

Reading two files consecutively should result in a hexadecimal display like:

00000000 02 00 08          80 fe  75 81 07 12 00 78 e5 82 ...   ..u....x..
00000010 60 03 02 00 03 79 00 e9  44 00 60 1b 7a 00 90 00 `....y..D.`.z...

where the corresponding bytes are either highlighted (when the definition in the 1st file differs from the 2nd file), normal (if same), obmitted or greyed out (if there is no definition in either of the files), be in color1 if only defined in the 1st file and color2 if only defined in the 2nd.

Writing a selection of the buffer (lets assume byte 0x000b to 0x000f in the example above) to an .hex or .s19 file should be possible starting with offset 0x000b, 0x0000 or a user specified address.

If you own any kind of consumer electronics product it's likely that these file formats were involved.

Text tools (srecord, binutils) for these formats exist but might present an inhibition for developers which are used to a graphical toolchain on other platforms.

Embedded developers targetting these devices (especially 8-bit targets) typically do not use Linux as a host platform. If there is a win over then I'd hope for better linux support (f.e. upgrading the firmware of some of these devices would not require buying the license of another operating system) and I'd hope for more openness with respect to protocols and linux drivers.

An anecdotical contribution relating to the importance of having developers for a specific platform: http://www.youtube.com/watch?v=8To-6VIJZRE

Outlook 

In the long run it might be possible to interface to flashprogrammers.

Related work

• okteta http://utils.kde.org/projects/okteta/
• srecord http://srecord.sf.net
• others http://en.wikipedia.org/wiki/Comparison_of_hex_editors
• flashrom http://www.coreboot.org/Flashrom

Related request: A five year old request for khexedit (predecessor of okteta), 20 votes http://bugs.kde.org/show_bug.cgi?id=94361

Persons to contact:

• Friedrich W. H. Kossebau (okteta)
• Peter Miller (SRecord)

Scope 

2 weeks+ (depending on the internal structure of the hex editor)

Comments

Wolfgang Denk wrote:

Hm... is this really needed? Ignoring the often existing restrictions
like segment structure, alignment to flash erase blocks  etc.  in  an
image file (which render such image editing useless and can be dealt
with  easier  by  regenerating  the  files  through  a  normal  build
process),  typical image conversions / manipulations can be performed
often quite easily by combinations of standard tools like objcopy and
the like...

I doubt that a general purpose tool can be designed that  covers  all
potential  use  cases, and combinations of the already existing tools
are usually pretty efficient.

---

Mike Frysinger wrote:

if you want something to just edit files, how about:
objcopy -I ihex -O binary "$1" "$1.tmp" && khexedit "$1.tmp" &&
objcopy -I binary -O ihex "$1.tmp" "$1" && rm -f "$1.tmp"

---

Frieder Ferlemann wrote:

> Hm... Is this really needed?

Short answer: Yes, these formats were implemented for a reason.

Long answer falls into 3 parts which basically say: a) others seem
to need it, b) others implemented it, c) plausible usage scenarios
exist

Ad a) there were some votes for the bugs.kde.org request

Ad b) rethorical question: should the authors of
      (http://www.hexedit.com/ http://www.kibria.de/frhed.html
      http://www.dataman.com/ http://www.conitec.net/ ....)
      be informed that they should drop intel hex/motorola s19
      support as that feature is a non-issue?

Ad c) Take an 8-bit device with an 1k bootloader, a serial number,
      a program and calibration data crammed into 8k
      (or 16k/32k/64k if you are lucky - evidently this is not
      a linux target:)
      How do you to communicate the following usage cases:
      1) upgrade only the program, 2) upgrade calibration data
      but not the program, 3) upgrade bootloader, program and
      calibration data but do not the touch serial number,
      4) upgrade bootloader and program but do not the touch
      serial number and do not touch calibration data.
      This *can* be the matter of transmitting a *single* .hex or .s19
      file respectively!
      (you can do with binary files and some binutils/srecord scripts
      too but you'd have to talk the customer into installing
      some tools in a Windows environment first, possibly get around
      limitations in command line length in above mentioned environment
      and then try to educate the customer to run a batch file from
      some directory where some files should reside and then feed
      the resulting file somewhere else. For one or the other reason
      one probably wouldn't do this for long:)
      Or consider a binary file with the content of the nonvolatile
      CMOS memory on a PC in which you'd want someone else (or a
      group of people) to set two bytes at two different positions
      to a specific value: You can tell to load the binary file into
      the editor, then load the .hex/.s19 file over it, then save
      again as binary.

At least being able to view and compare these files visually would be
helpful. (Yes I know objcopy (I did mention binutils in the proposal),
srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))

---

Mike Frysinger wrote:

Your examples don't really sound like justification to me.  It sounds
like you simply need a tiny amount of metadata surrounding the transfer
to communicate whatever needs updating.  Plus, how is this relevant at
all to "tool for editing files"?  Plus plus, you yourself already said
there are multiple tools that can already edit ihex/srec files natively.

I don't see anything new/useful/innovative in this proposal.