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

[Joerg Wunsch]

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.

> 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.)

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).  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.  Does that really make sense to
you?  To me, it doesn't.  As ugly as it is, I'd then rather stay with
all the various offsets.

> >   Again, it doesn't solve anything that could not likewise be solved
> >   by applying the already established offset 0x820000.

> True, execept that those offsets are also arbitrary and they also
> become "magic numbers" instead of having meaningful names.

Yes, they are magic, but they are not user-visible (well, to some degree,
they are, but that's most annyoing for SRAM where you cannot avoid it
anyway).

> > . 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.  Just run avr-objcopy without any -j or
--change-section-lma options, and you'll yield exactly that file.  It
will contain the entire containts of all loaded sections (text, data,
eeprom, fuse) flattened to one file, but no meta information (symbol
table, debugging information).

No three, four, or five hex files needed.

Of course, I don't say this should completely obviate the need for
also reading ELF files.  There's not much point in running the
avr-objcopy step into an ihex file at all if we also could get the
same information from the ELF file.

Btw., that's what AVaRICE used to do for years (except they didn't
extend the idea to fuses).

> 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.  Right now, the
Atmel tools don't have any option to handle fuse file settings as
being part of a load file anyway (only specified on the command-line,
similar to the "m" option of avrdude), so it would be a worthwhile
addition.

> If we have a single ELF file, then why can't we just use section
> names, and why do we need to have arbitrary offsets?

Because we already need offsets for at least two memory spaces anyway
(flash ROM and EEPROM where we cannot get rid of it), and I don't see
a point in having two different methods for the same purpose
(distinction of target memory spaces).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)