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

[Colin O'Flynn]

Hello,

>Let's face it,
> people *do* invent their own section names, so we simply have to cope
> with it. 

For flash I do use the offset, it builds the image by getting any section with 
the proper flags set in the text area.

I do not do that for eeprom though - and it would be forseeable for someone to 
make their own section in that area.

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. Using the 
lfuse/fuse/hfuse/efuse names would help ensure you aren't getting that! As a 
saftey measure maybe I should check the address too, so both have to match?

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

> 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. I would 
add some #ifdefs in the code to deal with this, but those don't do anything 
without the script that actually listens to what the user wants ;-)

> Also, I'm not quite sure, does the syntax of this extension still
> allow to select individual memory spaces from the ELF file, so you
> could e.g. only update the flash ROM but not clobber the EEPROM?

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.

After this is all sorted out and commited, then the magic mode could be added. 
There was a lot of discussion on that earlier so I hoped to just add ELF 
support without anyone getting mad yet!

Warm Regards,

 -Colin

On Monday 07 May 2007 18:11, Joerg Wunsch wrote:
> As Colin O Flynn wrote:
> > Check to work with Mega128 128 KB, and does work with
> > lfuse/hfuse/efuse memory spaces.
> >
> > I'd like to see this get into CVS, as it would add ELF support to
> > avrdude.
>
> I'm afraid I never really continued on that discussion before (though
> I intented to), sorry for that!
>
> 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.  In
> fact, I've been thinking about that option way before, and I think
> even Brian Dean once mentioned that idea, years ago.
>
> However, I'm completely against hardcoding section names from ELF
> files.  AVR Studio did that mistake before, and the result was that
> people could not debug their .bootloader sections.  Let's face it,
> people *do* invent their own section names, so we simply have to cope
> with it.  Eric, as little as you like it (I don't really like it
> either), these magic memory offsets are by now our only real
> distinction between different memory spaces of the AVR.  These offsets
> are simply required until the day the entire GNU toolchain has been
> taught to handle multiple target memory spaces without flattening them
> into a single large one (which I don't see any volunteer for so far).
> So let's use the same memory offsets AVaRICE is already using:
>
>     FLASH_SPACE_ADDR_OFFSET           = 0x000000,
>     DATA_SPACE_ADDR_OFFSET            = 0x800000,
>
>     EEPROM_SPACE_ADDR_OFFSET          = 0x810000,
>
>     FUSE_SPACE_ADDR_OFFSET            = 0x820000,
>
>     LOCK_SPACE_ADDR_OFFSET            = 0x830000,
>
>     SIG_SPACE_ADDR_OFFSET             = 0x840000,
>
>     BREAKPOINT_SPACE_ADDR_OFFSET      = 0x900000,
>
> (We don't need all of them in avrdude.)
>
> I understand your concerns about the 8 MiB limit to the flash space
> imposed by this.  However, I don't see this limit being hit even in
> the near future (the XMega roadmap has been at least semi-public on
> avrfreaks.net), and after all, avrdude could still make them
> configurable on a per-part basis in avrdude.conf if we desire.
>
> Also, I'm not quite sure, does the syntax of this extension still
> allow to select individual memory spaces from the ELF file, so you
> could e.g. only update the flash ROM but not clobber the EEPROM?