avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Weddington
Subject: RE: [avrdude-dev] [task #5093] Add support for reading ELF files.
Date: Tue, 08 May 2007 06:39:07 -0600

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> rg] On Behalf Of Joerg Wunsch
> Sent: Tuesday, May 08, 2007 6:02 AM
> To: address@hidden
> Subject: Re: [avrdude-dev] [task #5093] Add support for 
> reading ELF files.
> 
> . 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?

I'm playing devil's advocate below:

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

One cannot make comparisons to the EEPROM section here. One can have
multiple .text or .eeprom sections and they will be concatenated or added
together in the set. With fuse sections, there is only 1 byte per section,
so there is nothing to add. Having multiple fuse sections would be
ridiculous.

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

Yes, it is arbitrary, but with 1 byte per section, so what? As long as all
the tools in the chain know what that section name is.

>   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.
 
> . 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. They are not mixed in to the same
file. Where should one put the fuse data? In the flash hex file? In the
eeprom hex file? In separate hex files? 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. Yes, we can modify avrdude and AVR Studio to
work with these "special" files, but there are many other tools out there
that work with standard Intel Hex files that will now be broken. This is one
reason why it is important to have avrdude (and eventually AVR Studio) to
work with the ELF files directly, because all of the sections are included
in a single file (ELF). If we work with hex files, the end user will be
working with 5 different hex files (flash, eeprom, lfuse, hfuse, efuse),
which is NOT what they want to do. They want a *single* file. 

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?
 
Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]