RE: [avrdude-dev] [task #5093] Add support for reading ELF files.

[Eric Weddington]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> rg] On Behalf Of Joerg Wunsch
> Sent: Tuesday, May 08, 2007 7:29 AM
> To: address@hidden
> Subject: Re: [avrdude-dev] [task #5093] Add support for 
> reading ELF files.
> 
> As Eric Weddington wrote:
> 
> > > . It cannot be made the universal decision base anyway.  See the
> > > AVR Studio failure for the .bootload section for an example.
> 
> > For some reason I'm drawing a blank on this; I can't seem to
> > remember the issue. Could you refresh my memory?
> 
> At least in some version, AVR Studio also had implied knowledge about
> the object file section names, and it only handled .text, .data, and
> .bss.  Perhaps that has been fixed since, it could be it has been in
> the COFF era.  My only point was that implied knowledge about names
> that can be otherwise freely used by the programmer is evil.

I agree that implied knowledge about names, *to the exclusion of others* is
evil. My avr-size patch to binutils is the devil itself in this regard and I
need to eventually fix it. ;-) So, in this regard, having a tool know about
.text, but then ignoring a user defined section that is also located in the
same address space is not a good thing.

 
> > One cannot make comparisons to the EEPROM section here.
> 
> Why not?  Technically, what's the difference between the array of
> EEPROM cells available through the EE* IO registers, and the array of
> EEPROM cells available as fuse bits?
> 
> > With fuse sections, there is only 1 byte per section,
> > so there is nothing to add.
> 
> (Or just one fuse sections with up to three bytes by now.)

I know that you lean towards having a single .fuse space with multiple
bytes. Can you answer these questions:
- How would a user specify the fuse information in their application (with a
proposed avr-libc API that was discussed)?
- How would a user specify each fuse byte individually?
- How would the user know which byte went to which fuse address location?

 
> My point is: relying on a section name adds another parameter that has
> not been used at all in the past, at least not inside the tools (only
> at the Makefile level). 

Adds a parameter to what?

 And unlike the offset hack, that parameter
> cannot be applied universally, so the old offset hack cannot be
> replaced by it.  But then, we'll end up in two things for the same
> purpose: to distinguish different target memory spaces, some of them
> would be recognized by section name, and some of them would be
> recognized by their internal offset.  

That is a bogus argument. The fuses don't necessarily have their own "target
memory spaces" because *they are never seen by the application*. To program
the fuses requires outside tools to do the job. The application can address
flash, sram, and eeprom. It cannot address the fuses. It doesn't matter if
the fuses have any offset at all and they only matter to programming
software and the programming software only looks at the data one or more
bytes.

> 
> > > . The offset hack can even be transported across non-section
> > > structured file format (like Intel hex), something that has been
> > > requestd as a feature here.
> 
> > Which is bogus. Right now, the tools put the flash data in one hex
> > file, and the eeprom data in a separate hex file.
> 
> Which has probably been a failure right from the beginning.  This
> distinction into multiple files has not been necessary at all.
> 
> > Where should one put the fuse data? In the flash hex file?
> 
> In the "universal" hex file.

The "universal hex file" is the resulting ELF file from the toolchain. The
only reason for Intel Hex files is for programming tools. This is now
changing where the programming tools now know about ELF files. Avarice can
program an AVR from the ELF file. AVR Studio can program the AVR from an ELF
file. Avrdude needs to have this capability. If they can all program the AVR
from an ELF file, then there is no need for them to work with multiple hex
files, or a bastardized hex file. They can look directly at the ELF
sections, and determine where all the various data needs to go and how to
get it there. What I am advocating is that we use this to our advantage, and
put things into the ELF file that we have always wanted and needed to do.
Even if we don't necessarily have the tools go off of fixed section names,
is there some other way, in the ELF file, to tag one or more sections, as
belonging to "fuses" without it having to have some magical address offset
that is bogus to begin with? If not, then it would make sense to break up
the fuse bytes into individual sections (1 byte per section) and have the
tools then work with these fixed section names, because they can't be
combined with any other section, and there is only one thing to do with such
a section, and that is to program the respective fuse with that information.

 
 
> > If one puts the fuse data in with the flash hex file, at these large
> > offsets, then standard tools will not be able to work with these
> > files.
> 
> Those tools that cannot handle the flattened hex file have to be fed
> their individual hex files as they got them by now.  They won't be
> helped with the ELF file approach either though.  However, we can
> teach avrdude to handle the flattened hex file, and we (i.e. you :)
> could perhaps even teach the Atmel tools to handle it.  

If we're moving towards using the ELF file for everything, then it doesn't
make sense to add the flat hex file capability to the tools.

Eric Weddington