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

[Joerg Wunsch]

As Eric Weddington wrote:

> Hmm. Can you explain your reasoning a bit more? I'm at a loss in
> understanding why we cannot reserve certain section names in the ELF
> file.

. Be consistent.  The existing scheme (use the well-established
  offsets) works fine, and there's no need to invent a parallel
  scheme.  The offsets are/have been in use by the entire toolchain.

. It cannot be made the universal decision base anyway.  See the AVR
  Studio failure for the .bootload section for an example.  Colin
  mentioned more examples: people might want to have more than one
  EEPROM section (e.g. to impose a certain externally-synchronized
  structure to their EEPROM data), so you could not rely on .eeprom
  being the only EEPROM section.  But now, if you cannot rely on some
  names, where are you drawing the line?  The chose of lfuse etc. is
  rather arbitrary, as obvious as it might be in the first place.
  Again, it doesn't solve anything that could not likewise be solved
  by applying the already established offset 0x820000.

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


As Colin O'Flynn wrote:

> For hfuse/lfuse/efuse/fuse section it seems unlikely you would
> invent your own section name though. As well if someone accidently
> put something in the fuse address space, you could get garbage
> programmed in.

They would need to modify their linker scripts for that to happen.
But then, they are responsible theirselves.

My idea about the fuse space is to still use section names on the
linker input, but then convert that into section name + offset at
linker output, just as it happens for .eeprom.

> However - if you'd rather see addresses used for the fuses, what
> should the layout be for fuse/lfuse/efuse/hfuse?

I'd vote again for a combined fuse address space.  IMHO it's been a
failure from Atmel to establish different names for the individual
fuses, rather than making them an array of fuse cells (which it
actually is).  The layout is simple: fuse = lfuse, hfuse, efuse.  Any
additional fuses (of future AVRs) could be added on the fly behind.

Basically, that's already the way the JTAG ICE handles the fuses (they
do have their own address space there).

> > I'm really fine with adding ELF support to avrdude though I'd like
> > to see it configure-time optional so people who don't want to
> > install the prerequisite libiberty and libbfd could continue as
> > they used to.

> Sounds good! Again I'm not quite sure how to edit the configure file.

You could have a look at the examples that are already there, like
libusb detection, and the various AC_ARG_ENABLE statements.

> Right now it *only* allows individual updates. So you have to
> specify lfuse, efuse, etc. It allows you to do:

> -U w:elfuse:main.elf -U w:flash:main.elf

> So you have the same file. This way it makes the minimal changes to
> the avrdude user interface, it pretty much only adds support for ELF
> file programming.

OK, I already thought of that, too.

> After this is all sorted out and commited, then the magic mode could
> be added.

Like -U w:*:main.elf :)

> There was a lot of discussion on that earlier so I hoped to just add
> ELF support without anyone getting mad yet!

You don't get me mad ;-), I always intended to write up all this
before, but somehow forgot about it.  I'm really sorry about that,
Colin.

Btw., I always thought that adding automatic fuse setting to the
compiler, library, and avrdude would be a good thing (and something
the PIC people did have years before).  I've been discussing that with
Brian Dean before, and also on and off in public forums.  I'm really
thankful that now finally, someone from Atmel (hi Eric :) is pushing
that issue.

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

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